draft-ietf-avt-rapid-acquisition-for-rtp-12.txt   draft-ietf-avt-rapid-acquisition-for-rtp-13.txt 
AVT B. VerSteeg AVT B. VerSteeg
Internet-Draft A. Begen Internet-Draft A. Begen
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: February 26, 2011 T. VanCaenegem Expires: February 27, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
August 25, 2010 August 26, 2010
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-12 draft-ietf-avt-rapid-acquisition-for-rtp-13
Abstract Abstract
When an RTP receiver joins a multicast session, it may need to When an RTP receiver joins a multicast session, it may need to
acquire and parse certain Reference Information before it can process acquire and parse certain Reference Information before it can process
any data sent in the multicast session. Depending on the join time, any data sent in the multicast session. Depending on the join time,
length of the Reference Information repetition (or appearance) length of the Reference Information repetition (or appearance)
interval, size of the Reference Information as well as the interval, size of the Reference Information as well as the
application and transport properties, the time lag before an RTP application and transport properties, the time lag before an RTP
receiver can usefully consume the multicast data, which we refer to receiver can usefully consume the multicast data, which we refer to
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 February 26, 2011. This Internet-Draft will expire on February 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 41 skipping to change at page 3, line 41
8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 37 8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 37
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 43 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 43
11.2. Registration of SDP Attribute Values . . . . . . . . . . . 43 11.2. Registration of SDP Attribute Values . . . . . . . . . . . 43
11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 43 11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 43
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 44 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 44
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 44 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 44
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 45 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 45
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 11.6.1. Response Code Definitions . . . . . . . . . . . . . . 48
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 49
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
14.1. Normative References . . . . . . . . . . . . . . . . . . . 48 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
14.2. Informative References . . . . . . . . . . . . . . . . . . 50 14.1. Normative References . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 14.2. Informative References . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
Most multicast flows carry a stream of inter-related data. The Most multicast flows carry a stream of inter-related data. The
receivers need to acquire certain information to start processing any receivers need to acquire certain information to start processing any
data sent in the multicast session. This document refers to this data sent in the multicast session. This document refers to this
information as Reference Information. The Reference Information is information as Reference Information. The Reference Information is
conventionally sent periodically in the multicast session (although conventionally sent periodically in the multicast session (although
its content can change over time) and usually consists of items such its content can change over time) and usually consists of items such
as a description of the schema for the rest of the data, references as a description of the schema for the rest of the data, references
skipping to change at page 47, line 39 skipping to change at page 47, line 39
507 BRS has no valid starting point available for 507 BRS has no valid starting point available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
508 BRS has no reference information available for 508 BRS has no reference information available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
509 BRS has no RTP stream matching the requested SSRC [RFCXXXX] 509 BRS has no RTP stream matching the requested SSRC [RFCXXXX]
510 RAMS request to acquire the entire session 510 RAMS request to acquire the entire session
has been denied [RFCXXXX] has been denied [RFCXXXX]
511 Only the preamble information is sent [RFCXXXX] 511 Only the preamble information is sent [RFCXXXX]
512 RAMS request has been denied due to a policy [RFCXXXX] 512 RAMS request has been denied due to a policy [RFCXXXX]
The definitions for these codes are provided in Section 11.6.1.
Any registration for an unassigned Response code needs to contain the Any registration for an unassigned Response code needs to contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new Response code describes and o A detailed description of what the new Response code describes and
how it shall be interpreted. how it shall be interpreted.
11.6.1. Response Code Definitions
o 100: This is used when the BRS wants to update a value that was
sent earlier to the RTP_Rx.
o 200: This is used when the server accepts the RAMS request.
o 201: This is used when the unicast burst has been completed and
the BRS wants to notify the RTP_Rx.
o 400: This is used when the RAMS-R message is improperly
formatted.
o 401: This is used when the minimum RAMS buffer fill requirement
value indicated in the RAMS-R message is invalid.
o 402: This is used when the maximum RAMS buffer fill requirement
value indicated in the RAMS-R message is invalid.
o 403: This is used when the maximum receive bitrate value
indicated in the RAMS-R message is invalid.
o 500: This is used when the BRS has experienced an internal error
and cannot accept the RAMS request.
o 501: This is used when the BRS does not have enough bandwidth to
send the unicast burst stream.
o 502: This is used when the BRS terminates the unicast burst
stream due to network congestion.
o 503: This is used when the BRS does not have enough CPU resources
to send the unicast burst stream.
o 504: This is used when the BRS does not support sending a unicast
burst stream.
o 505: This is used when the requesting RTP_Rx is not eligible to
receive a unicast burst stream.
o 506: This is used when RAMS functionality is not enabled for the
requested multicast stream.
o 507: This is used when the BRS cannot find a valid starting point
for the unicast burst stream satisfying the RTP_Rx's requirements.
o 508: This is used when the BRS cannot find the essential
reference information for the requested multicast stream.
o 509: This is used when the BRS cannot match the requested SSRC to
any of the streams it is serving.
o 510: This is used when the BRS cannot serve the requested entire
session.
o 511: This is used when the BRS sends only the preamble
information but not the whole unicast burst stream.
o 512: This is used when the RAMS request is denied due to a policy
specified for the requested multicast stream, requesting RTP_Rx or
this particular BRS.
12. Contributors 12. Contributors
Dave Oran, Magnus Westerlund and Colin Perkins have contributed Dave Oran, Magnus Westerlund and Colin Perkins have contributed
significantly to this specification by providing text and solutions significantly to this specification by providing text and solutions
to some of the issues raised during the development of this to some of the issues raised during the development of this
specification. specification.
13. Acknowledgments 13. Acknowledgments
The following individuals have reviewed the earlier versions of this The following individuals have reviewed the earlier versions of this
skipping to change at page 49, line 45 skipping to change at page 51, line 11
Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", draft-ietf-avt-rapid-rtp-sync-12 (work in Flows", draft-ietf-avt-rapid-rtp-sync-12 (work in
progress), July 2010. progress), July 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[I-D.ietf-avt-rtcp-port-for-ssm] [I-D.ietf-avt-rtcp-port-for-ssm]
Begen, A., "RTP Control Protocol (RTCP) Port for Source- Begen, A., "RTP Control Protocol (RTCP) Port for Source-
Specific Multicast (SSM) Sessions", Specific Multicast (SSM) Sessions",
draft-ietf-avt-rtcp-port-for-ssm-01 (work in progress), draft-ietf-avt-rtcp-port-for-ssm-02 (work in progress),
August 2010. August 2010.
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] [I-D.ietf-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions", Multicast RTP Sessions",
draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in
progress), May 2010. progress), May 2010.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
skipping to change at page 50, line 35 skipping to change at page 51, line 49
August 1980. August 1980.
[I-D.begen-avt-rams-scenarios] [I-D.begen-avt-rams-scenarios]
Begen, A., "Considerations for RAMS Scenarios", Begen, A., "Considerations for RAMS Scenarios",
draft-begen-avt-rams-scenarios-00 (work in progress), draft-begen-avt-rams-scenarios-00 (work in progress),
October 2009. October 2009.
[I-D.ietf-avt-rtp-cnames] [I-D.ietf-avt-rtp-cnames]
Begen, A., Perkins, C., and D. Wing, "Guidelines for Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", draft-ietf-avt-rtp-cnames-00 (work in (CNAMEs)", draft-ietf-avt-rtp-cnames-01 (work in
progress), June 2010. progress), August 2010.
[I-D.ietf-avt-multicast-acq-rtcp-xr] [I-D.ietf-avt-multicast-acq-rtcp-xr]
Begen, A. and E. Friedrich, "Multicast Acquisition Report Begen, A. and E. Friedrich, "Multicast Acquisition Report
Block Type for RTP Control Protocol (RTCP) Extended Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-01 Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-01
(work in progress), May 2010. (work in progress), May 2010.
[I-D.ietf-avt-ecn-for-rtp] [I-D.ietf-avt-ecn-for-rtp]
Westerlund, M., Johansson, I., Perkins, C., and K. Westerlund, M., Johansson, I., Perkins, C., and K.
Carlberg, "Explicit Congestion Notification (ECN) for RTP Carlberg, "Explicit Congestion Notification (ECN) for RTP
 End of changes. 9 change blocks. 
13 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/