draft-ietf-avtext-rams-scenarios-03.txt   draft-ietf-avtext-rams-scenarios-04.txt 
AVTEXT A. Begen AVTEXT A. Begen
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational March 9, 2012 Intended status: Informational April 18, 2012
Expires: September 10, 2012 Expires: October 20, 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-03 draft-ietf-avtext-rams-scenarios-04
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 September 10, 2012. This Internet-Draft will expire on October 20, 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 29 skipping to change at page 2, line 29
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 3. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 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
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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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 We run an individual RAMS session for each of these RTP streams that
we want to rapidly acquire. Each requires a separate RAMS Request we want to rapidly acquire. 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
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
a=group:FEC-FR Channel1_Video Channel1_FEC a=group:FEC-FR Channel1_Video Channel1_FEC
m=video 40000 RTP/AVPF 96 m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
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=mid:Channel1_Video a=mid:Channel1_Video
m=application 40000 RTP/AVPF 97 m=application 40000 RTP/AVPF 97
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
skipping to change at page 6, line 5 skipping to change at page 6, line 5
The RAMS Request message sent by an RTP receiver to the feedback The RAMS Request message sent by an RTP receiver to the feedback
target could indicate the desire to acquire all or a subset or one of target could indicate the desire to acquire all or a subset or one of
the available RTP streams. Thus, both the primary video and audio the available RTP streams. Thus, both the primary video and audio
streams can be acquired rapidly in parallel. Or, the RTP receiver streams can be acquired rapidly in parallel. Or, the RTP receiver
can acquire only the primary video or audio stream, if desired, by can acquire only the primary video or audio stream, if desired, by
indicating the specific SSRC in the request. Compared to the indicating the specific SSRC in the request. Compared to the
previous scenario, the only difference is that in this case the join previous scenario, the only difference is that in this case the join
times for both streams need to be coordinated as they are delivered times for both streams need to be coordinated as they are delivered
in the same multicast session. in the same multicast session.
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
m=video 40000 RTP/AVPF 96 m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
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=mid:Channel1_Video a=mid:Channel1_Video
m=audio 40001 RTP/AVPF 97 m=audio 40001 RTP/AVPF 97
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
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
skipping to change at page 7, line 5 skipping to change at page 7, line 5
the SSM session carries both the primary video and audio stream, the SSM session carries both the primary video and audio stream,
destined to the same port. destined to the same port.
Similar to scenario #2, both the primary video and audio streams can Similar to scenario #2, both the primary video and audio streams can
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 or audio stream, if desired, by indicating the only the primary video or audio stream, if desired, by indicating the
specific SSRC in the request. In this case, there is only one specific SSRC in the request. In this case, there is only one
distribution source and the destination multicast address is shared. distribution source and the destination multicast address is shared.
Thus, there is always one SSM session and one feedback target. Thus, there is always one SSM session and one feedback target.
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
m=video 40000 RTP/AVPF 96 97 m=video 40000 RTP/AVPF 96 97
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
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
skipping to change at page 8, line 18 skipping to change at page 8, line 20
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
receiving the FEC stream after the acquisition of the primary video receiving the FEC stream after the acquisition of the primary video
stream has been completed). stream has been completed).
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
a=group:FEC-FR Channel1_Video Channel1_FEC a=group:FEC-FR Channel1_Video Channel1_FEC
m=video 40000 RTP/AVPF 96 m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
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=rtpmap:96 MP2T/90000 a=rtpmap:96 MP2T/90000
b=TIAS:10000 b=TIAS:10000
a=ssrc:1 cname:ch1_video@example.com a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video a=mid:Channel1_Video
m=application 40000 RTP/AVPF 97 m=application 40000 RTP/AVPF 97
skipping to change at page 9, line 13 skipping to change at page 9, line 20
While the RTP receiver can update the Max Receive Bitrate values While the RTP receiver can update the Max Receive Bitrate values
during the course of the RAMS session, this approach is more error- during the course of the RAMS session, this approach is more error-
prone due to the possibility of losing the update messages. prone due to the possibility of losing the update messages.
5.2. Scenario #2 5.2. Scenario #2
Here RTP streams 1 (primary video) and 2 (FEC) are transmitted over Here RTP streams 1 (primary video) and 2 (FEC) are transmitted over
the same multicast group with different destination ports. This is the same multicast group with different destination ports. This is
not a preferred deployment model. not a preferred deployment model.
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
a=group:FEC-FR Channel1_Video Channel1_FEC a=group:FEC-FR Channel1_Video Channel1_FEC
m=video 40000 RTP/AVPF 96 m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
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=rtpmap:96 MP2T/90000 a=rtpmap:96 MP2T/90000
b=TIAS:10000 b=TIAS:10000
a=ssrc:1 cname:ch1_video@example.com a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video a=mid:Channel1_Video
m=application 40001 RTP/AVPF 97 m=application 40001 RTP/AVPF 97
skipping to change at page 10, line 5 skipping to change at page 10, line 14
Mbps. Regardless of whether FEC is desired or not by the RTP Mbps. Regardless of whether FEC is desired or not by the RTP
receiver, its bitrate needs to be taken into account once the RTP receiver, its bitrate needs to be taken into account once the RTP
receiver joins the SSM session. receiver joins the SSM session.
5.3. Scenario #3 5.3. Scenario #3
This is the scenario for SSRC multiplexing where both RTP streams are This is the scenario for SSRC multiplexing where both RTP streams are
transmitted over the same multicast group to the same destination transmitted over the same multicast group to the same destination
port. port.
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
m=video 40000 RTP/AVPF 96 97 m=video 40000 RTP/AVPF 96 97
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
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=rtpmap:96 MP2T/90000 a=rtpmap:96 MP2T/90000
a=rtpmap:97 1d-interleaved-parityfec/90000 a=rtpmap:97 1d-interleaved-parityfec/90000
a=fmtp:97 L=10; D=10; repair-window=200000 a=fmtp:97 L=10; D=10; repair-window=200000
a=ssrc:1 cname:ch1_video@example.com a=ssrc:1 cname:ch1_video@example.com
a=ssrc:2 cname:ch1_fec@example.com a=ssrc:2 cname:ch1_fec@example.com
b=TIAS:11000 b=TIAS:11000
 End of changes. 12 change blocks. 
9 lines changed or deleted 33 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/