Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5760

RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback

Pages: 66
Proposed Standard
Errata
Updated by:  6128
Part 1 of 3 – Pages 1 to 13
None   None   Next

Top   ToC   RFC5760 - Page 1
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 Feedback

Abstract

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
Top   ToC   RFC5760 - Page 2
   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
Top   ToC   RFC5760 - Page 3

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
Top   ToC   RFC5760 - Page 4
   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
Top   ToC   RFC5760 - Page 5

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
Top   ToC   RFC5760 - Page 6
      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
Top   ToC   RFC5760 - Page 7
   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.
Top   ToC   RFC5760 - Page 8
   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.
Top   ToC   RFC5760 - Page 9
                                        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.
Top   ToC   RFC5760 - Page 10
   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:
Top   ToC   RFC5760 - Page 11
   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
Top   ToC   RFC5760 - Page 12
   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.
Top   ToC   RFC5760 - Page 13
   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)

Next Section