RFC 5760
RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback
Internet Engineering Task Force (IETF) J. Ott Request for Comments: 5760 Aalto University Category: Standards Track J. Chesterfield ISSN: 2070-1721 University of Cambridge E. Schooler Intel February 2010 RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast FeedbackAbstract
This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5760. Copyright Notice Copyright (c) 2010 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.Table of Contents
1. Introduction ....................................................3 2. Conventions and Acronyms ........................................4 3. Definitions .....................................................5 4. Basic Operation .................................................6 5. Packet Types ...................................................10 6. Simple Feedback Model ..........................................11 7. Distribution Source Feedback Summary Model .....................13 8. Mixer/Translator Issues ........................................36 9. Transmission Interval Calculation ..............................37 10. SDP Extensions ................................................39 11. Security Considerations .......................................41 12. Backwards Compatibility .......................................51 13. IANA Considerations ...........................................51 14. References ....................................................53 Appendix A. Examples for Sender-Side Configurations ...............57 Appendix B. Distribution Report Processing at the Receiver ........60
1. Introduction
The Real-time Transport Protocol (RTP) [1] provides a real-time transport mechanism suitable for unicast or multicast communication between multimedia applications. Typical uses of RTP are for real- time or near real-time group communication of audio and video data streams. An important component of the RTP protocol is the control channel, defined as the RTP Control Protocol (RTCP). RTCP involves the periodic transmission of control packets between group members, enabling group size estimation and the distribution and calculation of session-specific information such as packet loss and round-trip time to other hosts. An additional advantage of providing a control channel for a session is that a third-party session monitor can listen to the traffic to establish network conditions and to diagnose faults based on receiver locations. RTP was designed to operate in either a unicast or multicast mode. In multicast mode, it assumes an Any Source Multicast (ASM) group model, where both one-to-many and many-to-many communication are supported via a common group address in the range 224.0.0.0 through 239.255.255.255. To enable Internet-wide multicast communication, intra-domain routing protocols (those that operate only within a single administrative domain, e.g., the Distance Vector Multicast Routing Protocol (DVMRP) [16] and Protocol Independent Multicast (PIM) [17][18]) are used in combination with inter-domain routing protocols (those that operate across administrative domain borders, e.g., Multicast BGP (MBGP) [19] and the Multicast Source Discovery Protocol (MSDP) [20]). Such routing protocols enable a host to join a single multicast group address and send data to or receive data from all members in the group with no prior knowledge of the membership. However, there is a great deal of complexity involved at the routing level to support such a multicast service in the network. Many-to-many communication is not always available or desired by all group applications. For example, with Source-Specific Multicast (SSM) [8][9] and satellite communication, the multicast distribution channel only supports source-to-receiver traffic. In other cases, such as large ASM groups with a single active data source and many passive receivers, it is sub-optimal to create a full routing-level mesh of multicast sources just for the distribution of RTCP control packets. Thus, an alternative solution is preferable. Although a one-to-many multicast topology may simplify routing and may be a closer approximation to the requirements of certain RTP applications, unidirectional communication makes it impossible for receivers in the group to share RTCP feedback information with other group members. In this document, we specify a solution to that problem. We introduce unicast feedback as a new method to distribute
RTCP control information amongst all session members. This method is
designed to operate under any group communication model, ASM or SSM.
The RTP data stream protocol itself is unaltered.
Scenarios under which the unicast feedback method can provide benefit
include but are not limited to:
a) SSM groups with a single sender.
The proposed extensions allow SSM groups that do not have many-to-
many communication capability to receive RTP data streams and to
continue to participate in the RTP control protocol (RTCP) by
using multicast in the source-to-receiver direction and unicast to
send receiver feedback to the source on the standard RTCP port.
b) One-to-many broadcast networks.
Unicast feedback may also be beneficial to one-to-many broadcast
networks, such as a satellite network with a terrestrial low-
bandwidth return channel or a broadband cable link. Unlike the
SSM network, these networks may have the ability for a receiver to
multicast return data to the group. However, a unicast feedback
mechanism may be preferable for routing simplicity.
c) ASM with a single sender.
A unicast feedback approach can be used by an ASM application with
a single sender to reduce the load on the multicast routing
infrastructure that does not scale as efficiently as unicast
routing does. Because this is no more efficient than a standard
multicast group RTP communication scenario, it is not expected to
replace the traditional mechanism.
The modifications proposed in this document are intended to
supplement the existing RTCP feedback mechanisms described in Section
6 of [1].
2. Conventions and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [13].
The following acronyms are used throughout this document:
ASM Any Source Multicast
SSM Source-Specific Multicast
3. Definitions
Distribution Source: In an SSM context, only one entity distributes RTP data and redistributes RTCP information to all receivers. This entity is called the Distribution Source. It is also responsible for forwarding RTCP feedback to the Media Senders and thus creates a virtual multicast environment in which RTP and RTCP can be applied. Note that heterogeneous networks consisting of ASM multiple-sender groups, unicast-only clients, and/or SSM single-sender receiver groups MAY be connected via translators or mixers to create a single-source group (see Section 8 for details). Media Sender: A Media Sender is an entity that originates RTP packets for a particular media session. In RFC 3550, a Media Sender is simply called a source. However, as the RTCP SSM system architecture includes a Distribution Source, to avoid confusion, in this document a media source is commonly referred to as a Media Sender. There may often be a single Media Sender that is co-located with the Distribution Source. But although there MUST be only one Distribution Source, there MAY be multiple Media Senders on whose behalf the Distribution Source forwards RTP and RTCP packets. RTP and RTCP Channels: The data distributed from the source to the receivers is referred to as the RTP channel and the control information as the RTCP channel. With standard RTP/RTCP, these channels typically share the same multicast address but are differentiated via port numbers as specified in [1]. In an SSM context, the RTP channel is multicast from the Distribution Source to the receivers. In contrast, the RTCP or feedback channel is actually the collection of unicast channels between the receivers and the Distribution Source via the Feedback Target(s). Thus, bidirectional communication is accomplished by using SSM in the direction from Distribution Source to the receivers and using the unicast feedback channel in the direction from receivers to Distribution Source. As discussed in the next section, the nature of the channels between the Distribution Source and the Media Sender(s) may vary. (Unicast RTCP) Feedback Target: The Feedback Target is a logical function to which RTCP unicast feedback traffic is addressed. The functions of the Feedback Target and the Distribution Source MAY be co-located or integrated in the same entity. In this case, for a session defined as having
a Distribution Source A, on ports n for the RTP channel and k for
the RTCP channel, the unicast RTCP Feedback Target is identified
by an IP address of Distribution Source A on port k, unless
otherwise stated in the session description. See Section 10 for
details on how the address is specified. The Feedback Target MAY
also be implemented in one or more entities different from the
Distribution Source, and different RTP receivers MAY use different
Feedback Target instances, e.g., for aggregation purposes. In
this case, the Feedback Target instance(s) MUST convey the
feedback received from the RTP receivers to the Distribution
Source using the RTCP mechanisms specified in this document. If
disjoint, the Feedback Target instances MAY be organized in
arbitrary topological structures: in parallel, hierarchical, or
chained. But the Feedback Target instance(s) and Distribution
Source MUST share, e.g., through configuration, enough information
to be able to provide coherent RTCP information to the RTP
receivers based upon the RTCP feedback collected by the Feedback
Target instance(s) -- as would be done if both functions were part
of the same entity.
In order for unicast feedback to work, each receiver MUST direct
its RTCP reports to a single specific Feedback Target instance.
SSRC:
Synchronization source as defined in [1]. This 32-bit value
uniquely identifies each member in a session.
Report blocks:
Report block is the standard terminology for an RTCP reception
report. RTCP [1] encourages the stacking of multiple report
blocks in Sender Report (SR) and Receiver Report (RR) packets. As
a result, a variable-size feedback packet may be created by one
source that reports on multiple other sources in the group. The
summarized reporting scheme builds upon this model through the
inclusion of multiple summary report blocks in one packet.
However, stacking of reports from multiple receivers is not
permitted in the Simple Feedback Model (see Section 6).
4. Basic Operation
As indicated by the definitions of the preceding section, one or more
Media Senders send RTP packets to the Distribution Source. The
Distribution Source relays the RTP packets to the receivers using a
source-specific multicast arrangement. In the reverse direction, the
receivers transmit RTCP packets via unicast to one or more instances
of the Feedback Target. The Feedback Target sends either the
original RTCP reports (the Simple Feedback Model) or summaries of
these reports (the Summary Feedback Model) to the Distribution
Source. The Distribution Source in turn relays the RTCP reports and/or summaries to the Media Senders. The Distribution Source also transmits the RTCP Sender Reports and Receiver Reports or summaries back to the receivers, using source-specific multicast. When the Feedback Target(s) are co-located (or integrated) with the Distribution Source, redistribution of original or summarized RTCP reports is trivial. When the Feedback Target(s) are physically and/or topologically distinct from the Distribution Source, each Feedback Target either relays the RTCP packets to the Distribution Source or summarizes the reports and forwards an RTCP summary report to the Distribution Source. Coordination between multiple Feedback Targets is beyond the scope of this specification. The Distribution Source MUST be able to communicate with all group members in order for either mechanism to work. The general architecture is displayed below in Figure 1. There may be a single Media Sender or multiple Media Senders (Media Sender i, 1<=i<=M) on whose behalf the Distribution Source disseminates RTP and RTCP packets. The base case, which is expected to be the most common case, is that the Distribution Source is co-located with a particular Media Sender. A basic assumption is that communication is multicast (either SSM or ASM) in the direction of the Distribution Source to the receivers (R(j), 1<=j<=N) and unicast in the direction of the receivers to the Distribution Source. Communication between Media Sender(s) and the Distribution Source may be performed in numerous ways: i. Unicast only: The Media Sender(s) MAY send RTP and RTCP via unicast to the Distribution Source and receive RTCP via unicast. ii. Any Source Multicast (ASM): The Media Sender(s) and the Distribution Source MAY be in the same ASM group, and RTP and RTCP packets are exchanged via multicast. iii. Source-Specific Multicast (SSM): The Media Sender(s) and the Distribution Source MAY be in an SSM group with the source being the Distribution Source. RTP and RTCP packets from the Media Senders are sent via unicast to the Distribution Source, while RTCP packets from the Distribution Source are sent via multicast to the Media Senders. Note that this SSM group MAY be identical to the SSM group used for RTP/RTCP delivery from the Distribution Source to the receivers or it MAY be a different one.
Note that Figure 1 below shows a logical diagram and, therefore, no details about the above options for the communication between Media Sender(s), Distribution Source, Feedback Target(s), and receivers are provided. Configuration information needs to be supplied so that (among other reasons): o Media Sender(s) know the transport address of the Distribution Source or the transport address of the (ASM or SSM) multicast group used for the contribution link; o the Distribution Source knows either the unicast transport address(es) or the (ASM or SSM) multicast transport address(es) to reach the Media Sender(s); o receivers know the addresses of their respectively responsible Feedback Targets; and o the Feedback Targets know the transport address of the Distribution Source. The precise setup and configuration of the Media Senders and their interaction with the Distribution Source is beyond the scope of this document (appropriate Session Description Protocol (SDP) descriptions MAY be used for this purpose), which only specifies how the various components interact within an RTP session. Informative examples for different configurations of the Media Sources and the Distribution Source are given in Appendix A. Future specifications may be defined to address these aspects.
Source-specific +--------+ +-----+ Multicast |Media | | | +----------------> R(1) |Sender 1|<----->| D S | | | +--------+ | I O | +--+ | | S U | | | | +--------+ | T R | | +-----------> R(2) | |Media |<----->| R C |->+ +---- : | | |Sender 2| | I E | | +------> R(n-1) | | +--------+ | B | | | | | | : | U | +--+--> R(n) | | | : | T +-| | | | | | I | |<---------+ | | | +--------+ | O |F|<---------------+ | | |Media | | N |T|<--------------------+ | |Sender M|<----->| | |<-------------------------+ +--------+ +-----+ Unicast FT = Feedback Target Transport from the Feedback Target to the Distribution Source is via unicast or multicast RTCP if they are not co-located. Figure 1: System Architecture The first method proposed to support unicast RTCP feedback, the 'Simple Feedback Model', is a basic reflection mechanism whereby all Receiver RTCP packets are unicast to the Feedback Target, which relays them unmodified to the Distribution Source. Subsequently, these packets are forwarded by the Distribution Source to all receivers on the multicast RTCP channel. The advantage of using this method is that an existing receiver implementation requires little modification in order to use it. Instead of sending reports to a multicast address, a receiver uses a unicast address yet still receives forwarded RTCP traffic on the multicast control channel. This method also has the advantage of being backwards compatible with standard RTP/RTCP implementations. The Simple Feedback Model is specified in Section 6. The second method, the 'Distribution Source Feedback Summary Model', is a summarized reporting scheme that provides savings in bandwidth by consolidating Receiver Reports at the Distribution Source, optionally with help from the Feedback Target(s), into summary packets that are then distributed to all the receivers. The Distribution Source Feedback Summary Model is specified in Section 7.
The advantage of the latter scheme is apparent for large group sessions where the basic reflection mechanism outlined above generates a large amount of packet forwarding when it replicates all the information to all the receivers. Clearly, this technique requires that all session members understand the new summarized packet format outlined in Section 7.1. Additionally, the summarized scheme provides an optional mechanism to send distribution information or histograms about the feedback data reported by the whole group. Potential uses for the compilation of distribution information are addressed in Section 7.4. To differentiate between the two reporting methods, a new SDP identifier is created and discussed in Section 10. The reporting method MUST be decided prior to the start of the session. A Distribution Source MUST NOT change the method during a session. In a session using SSM, the network SHOULD prevent any multicast data from the receiver being distributed further than the first hop router. Additionally, any data heard from a non-unicast-capable receiver by other hosts on the same subnet SHOULD be filtered out by the host IP stack so that it does not cause problems with respect to the calculation of the receiver RTCP bandwidth share.5. Packet Types
The RTCP packet types defined in [1], [26], and [15] are: Type Description Payload number ------------------------------------------------------- SR Sender Report 200 RR Receiver Report 201 SDES Source Description 202 BYE Goodbye 203 APP Application-Defined 204 RTPFB Generic RTP feedback 205 PSFB Payload-specific feedback 206 XR RTCP Extension 207 This document defines one further RTCP packet format: Type Description Payload number --------------------------------------------------------- RSI Receiver Summary Information 209 Within the Receiver Summary Information packet, there are various types of information that may be reported and encapsulated in optional sub-report blocks:
Name Long Name Value ------------------------------------------------------------------ IPv4 Address IPv4 Feedback Target Address 0 IPv6 Address IPv6 Feedback Target Address 1 DNS Name DNS name indicating Feedback Target Address 2 Reserved Reserved for Assignment by Standards Action 3 Loss Loss distribution 4 Jitter Jitter distribution 5 RTT Round-trip time distribution 6 Cumulative loss Cumulative loss distribution 7 Collisions SSRC collision list 8 Reserved Reserved for Assignment by Standards Action 9 Stats General statistics 10 RTCP BW RTCP bandwidth indication 11 Group Info RTCP group and average packet size 12 - Unassigned 13 - 255 As with standard RTP/RTCP, the various reports MAY be combined into a single RTCP packet, which SHOULD NOT exceed the path MTU. Packets continue to be sent at a rate that is inversely proportional to the group size in order to scale the amount of traffic generated.6. Simple Feedback Model
6.1. Packet Formats
The Simple Feedback Model uses the same packet types as traditional RTCP feedback described in [1]. Receivers still generate Receiver Reports with information on the quality of the stream received from the Distribution Source. The Distribution Source still MUST create Sender Reports that include timestamp information for stream synchronization and round-trip time calculation. Both Media Senders and receivers are required to send SDES packets as outlined in [1]. The rules for generating BYE and APP packets as outlined in [1] also apply.6.2. Distribution Source Behavior
For the Simple Feedback Model, the Distribution Source MUST provide a basic packet-reflection mechanism. It is the default behavior for any Distribution Source and is the minimum requirement for acting as a Distribution Source to a group of receivers using unicast RTCP feedback. The Distribution Source (unicast Feedback Target) MUST listen for unicast RTCP data sent to the RTCP port. All valid unicast RTCP packets received on this port MUST be forwarded by the Distribution Source to the group on the multicast RTCP channel. The Distribution
Source MUST NOT stack report blocks received from different receivers into one packet for retransmission to the group. Every RTCP packet from each receiver MUST be reflected individually. If the Media Sender(s) are not part of the SSM group for RTCP packet reflection, the Distribution Source MUST also forward the RTCP packets received from the receivers to the Media Sender(s). If there is more than one Media Sender and these Media Senders do not communicate via ASM with the Distribution Source and each other, the Distribution Source MUST forward each RTCP packet originated by one Media Sender to all other Media Senders. The Distribution Source MUST forward RTCP packets originating from the Media Sender(s) to the receivers. The reflected or forwarded RTCP traffic SHOULD NOT be counted as its own traffic in the transmission interval calculation by the Distribution Source. In other words, the Distribution Source SHOULD NOT consider reflected packets as part of its own control data bandwidth allowance. However, reflected packets MUST be processed by the Distribution Source and the average RTCP packet size, RTCP transmission rate, and RTCP statistics MUST be calculated. The algorithm for computing the allowance is explained in Section 9.6.3. Disjoint Distribution Source and Feedback Target(s)
If the Feedback Target function is disjoint from the Distribution Source, the Feedback Target(s) MUST forward all RTCP packets from the receivers or another Feedback Target -- directly or indirectly -- to the Distribution Source.6.4. Receiver Behavior
Receivers MUST listen on the RTP channel for data and on the RTCP channel for control. Each receiver MUST calculate its share of the control bandwidth R/n, in accordance with the profile in use, so that a fraction of the RTCP bandwidth, R, allocated to receivers is divided equally between the number of unique receiver SSRCs in the session, n. R may be rtcp_bw * 0.75 or rtcp_bw * 0.5 (depending on the ratio of senders to receivers as per [1]) or may be set explicitly by means of an SDP attribute [10]. See Section 9 for further information on the calculation of the bandwidth allowance. When a receiver is eligible to transmit, it MUST send a unicast Receiver Report packet to the Feedback Target following the rules defined in Section 9.
When a receiver observes either RTP packets or RTCP Sender Reports from a Media Sender with an SSRC that collides with its own chosen SSRC, it MUST change its own SSRC following the procedures of [1]. The receiver MUST do so immediately after noticing and before sending any (further) RTCP feedback messages. If a receiver has out-of-band information available about the Media Sender SSRC(s) used in the media session, it MUST NOT use the same SSRC for itself. Even if such out-of-band information is available, a receiver MUST obey the above collision-resolution mechanisms. Further mechanisms defined in [1] apply for resolving SSRC collisions between receivers.6.5. Media Sender Behavior
Media Senders listen on a unicast or multicast transport address for RTCP reports sent by the receivers (and forwarded by the Distribution Source) or other Media Senders (forwarded by the Distribution Source if needed). Processing and general operation follows [1]. A Media Sender that observes an SSRC collision with another entity that is not also a Media Sender MAY delay its own collision- resolution actions as per [1], by 5 * 1.5 * Td, with Td being the deterministic calculated reporting interval, for receivers to see whether the conflict still exists. SSRC collisions with other Media Senders MUST be acted upon immediately. Note: This gives precedence to Media Senders and places the burden of collision resolution on the RTP receivers. Sender SSRC information MAY be communicated out-of-band, e.g., by means of SDP media descriptions. Therefore, senders SHOULD NOT change their own SSRC aggressively or unnecessarily.
(page 13 continued on part 2)
