draft-ietf-avtext-rams-scenarios-04.txt   draft-ietf-avtext-rams-scenarios-05.txt 
AVTEXT A. Begen AVTEXT A. Begen
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational April 18, 2012 Intended status: Informational May 10, 2012
Expires: October 20, 2012 Expires: November 11, 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-04 draft-ietf-avtext-rams-scenarios-05
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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 October 20, 2012. This Internet-Draft will expire on November 11, 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 2, line 31 skipping to change at page 2, line 31
3.1. Scenario #1: Two Multicast Groups . . . . . . . . . . . . 4 3.1. Scenario #1: Two Multicast Groups . . . . . . . . . . . . 4
3.2. Scenario #2: One Multicast Group . . . . . . . . . . . . . 5 3.2. Scenario #2: One Multicast Group . . . . . . . . . . . . . 5
3.3. Scenario #3: SSRC Multiplexing . . . . . . . . . . . . . . 6 3.3. Scenario #3: SSRC Multiplexing . . . . . . . . . . . . . . 6
3.4. Scenario #4: Payload-Type Multiplexing . . . . . . . . . . 7 3.4. Scenario #4: Payload-Type Multiplexing . . . . . . . . . . 7
4. Feedback Target and SSRC Signaling Issues . . . . . . . . . . 7 4. Feedback Target and SSRC Signaling Issues . . . . . . . . . . 7
5. FEC during RAMS and Bandwidth Issues . . . . . . . . . . . . . 7 5. FEC during RAMS and Bandwidth Issues . . . . . . . . . . . . . 7
5.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
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
skipping to change at page 3, line 30 skipping to change at page 3, line 30
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 There are certain deployment models where a multicast RTP session
might have two or more multicast streams associated with it. There might have two or more multicast streams associated with it. There
are also cases, where an RTP receiver might be interested in are also cases, where an RTP receiver might be interested in
acquiring one or more multicast streams from several multicast RTP acquiring one or more multicast streams from several multicast RTP
sessions. In scenarios where multiple RAMS sessions, each initiated sessions. Close coordination is required for multiple RAMS sessions
with an individual RAMS Request message to a different feedback simultaneously started by an RTP server, where each session is
target, will be simultaneously run by an RTP receiver, they need to initiated with an individual RAMS Request message to a different
be coordinated. In this document, we present scenarios from real- feedback target. In this document, we present scenarios from real-
life deployments and discuss how the RAMS solution could be used in life deployments and discuss how the RAMS solution could be used in
such scenarios. 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 in some manner associated with each other. These
be audio and video elementary streams for the same TV channel, or could be audio and video elementary streams for the same TV channel,
they could be an MPEG2-TS stream (that has audio and video or 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.
An SSM session is defined by its (distribution) source address and An SSM session is defined by its (distribution) source address and
(destination) multicast group and there can be only one feedback (destination) multicast group and there can be only one feedback
target per SSM session [RFC5760]. So, if the RTP streams are target per SSM session [RFC5760]. So, if the RTP streams are
distributed by different sources or over different multicast groups, distributed by different sources or over different multicast groups,
they are considered different SSM sessions. While different SSM they are considered different SSM sessions. While different SSM
sessions can normally share the same feedback target address and/or sessions can normally share the same feedback target address and/or
port, RAMS requires each unique feedback target (i.e., the port, RAMS requires each unique feedback target (i.e., the
combination of address and port) to be associated with at most one combination of address and port) to be associated with at most one
skipping to change at page 4, line 37 skipping to change at page 4, line 37
3. Example Scenarios 3. Example Scenarios
3.1. Scenario #1: Two Multicast Groups 3.1. Scenario #1: Two Multicast Groups
This is the scenario for session multiplexing where RTP streams 1 and This is the scenario for session multiplexing where RTP streams 1 and
2 are transmitted over different multicast groups. A practical use 2 are transmitted over different multicast groups. A practical use
case is where the first and second SSM sessions carry the primary case is where the first and second SSM sessions carry the primary
video stream and its associated FEC stream, respectively. video stream and its associated FEC stream, respectively.
We run an individual RAMS session for each of these RTP streams that An individual RAMS sesson is run for each of the RTP streams that
we want to rapidly acquire. Each requires a separate RAMS Request requires rapid acquisition. Each requires a separate RAMS Request
message to be sent. These RAMS sessions can be run in parallel. If message to be sent. These RAMS sessions can be run in parallel. If
they are, the RTP receiver needs to pay attention to using the shared they are, the RTP receiver needs to pay attention to using the shared
bandwidth appropriately among the two unicast bursts. As explained bandwidth appropriately among the two unicast bursts. As explained
earlier, there has to be a different feedback target for these two earlier, there has to be a different feedback target for these two
SSM sessions. SSM sessions.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios s=RAMS Scenarios
t=0 0 t=0 0
skipping to change at page 7, line 21 skipping to change at page 7, line 21
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1 a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:1 cname:ch1_video@example.com a=ssrc:1 cname:ch1_video@example.com
a=ssrc:2 cname:ch1_audio@example.com a=ssrc:2 cname:ch1_audio@example.com
a=mid:Channel1 a=mid:Channel1
3.4. Scenario #4: Payload-Type Multiplexing 3.4. Scenario #4: Payload-Type Multiplexing
This is the scenario for payload-type multiplexing. This is the scenario for payload-type multiplexing.
In this case, instead of two, we have only one RTP stream (and one In this case, instead of two, there is only one RTP stream (and one
RTP session) carrying both payload types (e.g., media payload and its RTP session) carrying both payload types (e.g., media payload and its
FEC data). While this scheme is permissible per [RFC3550], it has FEC data). While this scheme is permissible per [RFC3550], it has
several drawbacks. For example, RTP packets carrying different several drawbacks. For example, RTP packets carrying different
payload formats will share the same sequence numbering space, and the payload formats will share the same sequence numbering space, and the
RAMS operations will not be able to be applied based on the payload RAMS operations will not be able to be applied based on the payload
type. For other drawbacks and details, see Section 5.2 of [RFC3550]. type. For other drawbacks and details, see Section 5.2 of [RFC3550].
4. Feedback Target and SSRC Signaling Issues 4. Feedback Target and SSRC Signaling Issues
The RAMS protocol uses the common packet format from [RFC4585], which The RAMS protocol uses the common packet format from [RFC4585], which
skipping to change at page 8, line 7 skipping to change at page 8, line 7
5. FEC during RAMS and Bandwidth Issues 5. FEC during RAMS and Bandwidth Issues
Suppose that RTP stream 1 denotes the primary video stream that has a Suppose that RTP stream 1 denotes the primary video stream that has a
bitrate of 10 Mbps and RTP stream 2 denotes the associated FEC stream bitrate of 10 Mbps and RTP stream 2 denotes the associated FEC stream
that has a bitrate of 1 Mbps. Also assume that the RTP receiver that has a bitrate of 1 Mbps. Also assume that the RTP receiver
knows that it can receive data at a maximum bitrate of 22 Mbps. SDP knows that it can receive data at a maximum bitrate of 22 Mbps. SDP
can specify the bitrate ("b=" line in Kbps) of each media session can specify the bitrate ("b=" line in Kbps) of each media session
(per "m" line). (per "m" line).
Note that RAMS can potentially congest the network temporarily.
Refer to [RFC6285] for detailed discussion.
5.1. Scenario #1 5.1. Scenario #1
This is the scenario for session multiplexing where RTP streams 1 and This is the scenario for session multiplexing where RTP streams 1 and
2 are transmitted over different multicast groups. 2 are transmitted over different multicast groups.
This is the preferred deployment model for FEC [RFC6363]. Having FEC This is the preferred deployment model for FEC [RFC6363]. Having FEC
in a different multicast group provides two flexibility points: RTP in a different multicast group provides two flexibility points: RTP
receivers that are not FEC capable can receive the primary video receivers that are not FEC capable can receive the primary video
stream without FEC, and RTP receivers that are FEC capable can decide stream without FEC, and RTP receivers that are FEC capable can decide
to not receive FEC during the rapid acquisition (but still start to not receive FEC during the rapid acquisition (but still start
skipping to change at page 10, line 41 skipping to change at page 10, line 45
be acquired rapidly in parallel. Or, the RTP receiver can acquire be acquired rapidly in parallel. Or, the RTP receiver can acquire
only the primary video stream, if desired, by indicating its specific only the primary video stream, if desired, by indicating its specific
SSRC in the request. SSRC in the request.
Note that based on the "a=fmtp" line for the FEC stream, it could be Note that based on the "a=fmtp" line for the FEC stream, it could be
possible to infer the bitrate of this FEC stream and set the Max possible to infer the bitrate of this FEC stream and set the Max
Receive Bitrate value accordingly. Receive Bitrate value accordingly.
6. Security Considerations 6. Security Considerations
There are no security considerations in this document. Because this document describes deployment scenarios for RAMS, all
security considerations are specified in the RAMS specifiction
[RFC6285].
7. IANA Considerations 7. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
Note to RFC Editor: You can remove this section (7) upon
publication.
8. Acknowledgments 8. Acknowledgments
I would like to thank various individuals in the AVTEXT and MMUSIC I would like to thank various individuals in the AVTEXT and MMUSIC
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,
 End of changes. 11 change blocks. 
16 lines changed or deleted 24 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/