tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5760

 
 
 

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

Part 3 of 3, p. 39 to 66
Prev RFC Part

 


prevText      Top      Up      ToC       Page 39 
10.  SDP Extensions

   The Session Description Protocol (SDP) [5] is used as a means to
   describe media sessions in terms of their transport addresses,
   codecs, and other attributes.  Signaling that RTCP feedback will be
   provided via unicast, as specified in this document, requires another
   session parameter in the session description.  Similarly, other SSM
   RTCP feedback parameters need to be provided, such as the
   summarization model at the sender and the target unicast address to
   which to send feedback information.  This section defines the SDP
   parameters that are needed by the proposed mechanisms in this
   document (and that have been registered with IANA).

10.1.  SSM RTCP Session Identification

   A new session-level attribute MUST be used to indicate the use of
   unicast instead of multicast feedback: "rtcp-unicast".

   This attribute uses one parameter to specify the model of operation.
   An optional set of parameters specifies the behavior for RTCP packet
   types (and subtypes).

   rtcp-unicast:reflection

      This attribute MUST be used to indicate the "Simple Feedback"
      model of operation where packet reflection is used by the
      Distribution Source (without further processing).

Top      Up      ToC       Page 40 
   rtcp-unicast:rsi *(SP <processing>:<rtcp-type>])

      This attribute MUST be used to indicate the "Distribution Source
      Feedback Summary" model of operation.  In this model, a list or
      parameters may be used to explicitly specify how RTCP packets
      originated by receivers are handled.  Options for processing a
      given RTCP packet type are:

      aggr:    The Distribution Source has means for aggregating the
               contents of the RTCP packets and will do so.

      forward: The Distribution Source will forward the RTCP packet
               unchanged.

      term:    The Distribution Source will terminate the RTCP packet.

   The default rules applying if no parameters are specified are as
   follows:

      RR and SDES packets MUST be aggregated and MUST lead to RSI
      packets being generated.  All other RTP packets MUST be terminated
      at the Distribution Source (or Feedback Target(s)).

      The SDP description needs only to specify deviations from the
      default rules.  Aggregation of RR packets and forwarding of SR
      packets MUST NOT be changed.

   The token for the new SDP attribute is "rtcp-unicast" and the formal
   SDP ABNF syntax for the new attribute value is as follows:

   att-value  = "reflection"
              / "rsi" *(SP rsi-rule)

   rsi-rule   = processing ":" rtcp-type

   processing = "aggr" / "forward" / "term" / token ;keep it extensible

   rtcp-type  = 3*3DIGIT    ;the RTCP type (192, 193, 202--209)

10.2.  SSM Source Specification

   In a Source-Specific Multicast RTCP session, the address of the
   Distribution Source needs to be indicated both for source-specific
   joins to the multicast group and for addressing unicast RTCP packets
   on the backchannel from receivers to the Distribution Source.

Top      Up      ToC       Page 41 
   This is achieved by following the proposal for SDP source filters
   documented in [4].  According to the specification, only the
   inclusion model ("a=source-filter:incl") MUST be used for SSM RTCP.

   There SHOULD be exactly one "a=source-filter:incl" attribute listing
   the address of the Distribution Source.  The RTCP port MUST be
   derived from the m= line of the media description.

   An alternative Feedback Target Address and port MAY be supplied using
   the SDP RTCP attribute [7], e.g., a=rtcp:<port> IN IP4 192.0.2.1.
   This attribute only defines the transport address of the Feedback
   Target and does not affect the SSM group specification for media
   stream reception.

   Two "source-filter" attributes MAY be present to indicate an IPv4 and
   an IPv6 representation of the same Distribution Source.

10.3.  RTP Source Identification

   The SSRC information for the Media Sender(s) MAY be communicated
   explicitly out of band (i.e., outside the RTP session).  One option
   for doing so is the Session Description Protocol (SDP) [5].  If such
   an indication is desired, the "ssrc" attribute [12] MUST be used for
   this purpose.  As per [12], the "cname" Source Attribute MUST be
   present.  Further Source Attributes MAY be specified as needed.

   If used in an SDP session description of an RTCP-SSM session, the
   ssrc MUST contain the SSRC intended to be used by the respective
   Media Sender and the cname MUST equal the CNAME for the Media Sender.
   If present, the role SHOULD indicate the function of the RTP entity
   identified by this line; presently, only the "media-sender" role is
   defined.

   Example:

       a=ssrc:314159 cname:iptv-sender@example.com

   In the above example, the Media Sender is identified to use the SSRC
   identifier 314159 and the CNAME iptv-sender@example.com.

11.  Security Considerations

   The level of security provided by the current RTP/RTCP model MUST NOT
   be diminished by the introduction of unicast feedback to the source.
   This section identifies the security weaknesses introduced by the
   feedback mechanism, potential threats, and level of protection that
   MUST be adopted.  Any suggestions on increasing the level of security

Top      Up      ToC       Page 42 
   provided to RTP sessions above the current standard are RECOMMENDED
   but OPTIONAL.  The final section outlines some security frameworks
   that are suitable to conform to this specification.

11.1.  Assumptions

   RTP/RTCP is a protocol that carries real-time multimedia traffic, and
   therefore a main requirement is for any security framework to
   maintain as low overhead as possible.  This includes the overhead of
   different applications and types of cryptographic operations as well
   as the overhead to deploy or to create security infrastructure for
   large groups.

   Although the distribution of session parameters (typically encoded as
   SDP objects) through the Session Announcement Protocol (SAP) [22],
   email, or the web is beyond the scope of this document, it is
   RECOMMENDED that the distribution method employs adequate security
   measures to ensure the integrity and authenticity of the information.
   Suitable solutions that meet the security requirements outlined here
   are included at the end of this section.

   In practice, the multicast and group distribution mechanism, e.g.,
   the SSM routing tree, is not immune to source IP address spoofing or
   traffic snooping; however, such concerns are not discussed here.  In
   all the following discussions, security weaknesses are addressed from
   the transport level or above.

11.2.  Security Threats

   Attacks on media distribution and the feedback architecture proposed
   in this document may take a variety of forms.  A detailed outline of
   the types of attacks follows:

   a) Denial of Service (DoS)

      DoS is a major area of concern.  Due to the nature of the
      communication architecture, a DoS can be generated in a number of
      ways by using the unicast feedback channel to the attacker's
      advantage.

   b) Packet Forgery

      Another potential area for attack is packet forgery.  In
      particular, it is essential to protect the integrity of certain
      influential packets since compromise could directly affect the
      transmission characteristics of the whole group.

Top      Up      ToC       Page 43 
   c) Session Replay

      The potential for session recording and subsequent replay is an
      additional concern.  An attacker may not actually need to
      understand packet content but simply have the ability to record
      the data stream and, at a later time, replay it to any receivers
      that are listening.

   d) Eavesdropping on a Session

      The consequences of an attacker eavesdropping on a session already
      constitutes a security weakness; in addition, eavesdropping might
      facilitate other types of attacks and is therefore considered a
      potential threat.  For example, an attacker might be able to use
      the eavesdropped information to perform an intelligent DoS attack.

11.3.  Architectural Contexts

   To better understand the requirements of the solution, the threats
   outlined above are addressed for each of the three communication
   contexts:

   a) Source-to-Receiver Communication

      The downstream communication channel, from the source to the
      receivers, is critical to protect since it controls the behavior
      of the group; it conveys the bandwidth allocation for each
      receiver, and hence the rate at which the RTCP traffic is unicast,
      directly back to the source.  All traffic that is distributed over
      the downstream channel is generated by a single source.  Both the
      RTP data stream and the RTCP control data from the source are
      included in this context, with the RTCP data generated by the
      source being indirectly influenced by the group feedback.

      The downstream channel is vulnerable to the four types of attack
      outlined above.  The denial of service attack is possible but less
      of a concern than the other types.  The worst case effect of DoS
      would be the transmission of large volumes of traffic over the
      distribution channel, with the potential to reach every receiver
      but only on a one-to-one basis.  Consequently, this threat is no
      more pronounced than the current multicast ASM model.  The real
      danger of denial of service attacks in this context comes
      indirectly via compromise of the source RTCP traffic.  If
      receivers are provided with an incorrect group size estimate or
      bandwidth allowance, the return traffic to the source may create a
      distributed DoS effect on the source.  Similarly, an incorrect
      feedback address -- whether as a result of a malicious attack or

Top      Up      ToC       Page 44 
      by mistake, e.g., an IP address configuration error (e.g., typing)
      -- could directly create a denial of service attack on another
      host.

      An additional concern relating to Denial of service attacks would
      come indirectly through the generation of fake BYE packets,
      causing the source to adjust the advertised group size.  A
      Distribution Source MUST follow the correct rules for timing out
      members in a session prior to reporting a change in the group
      size, which allows the authentic SSRC sufficient time to continue
      to report and, consequently, cancel the fake BYE report.

      The danger of packet forgery in the worst case may be to
      maliciously instigate a denial of service attack, e.g., if an
      attacker were capable of spoofing the source address and injecting
      incorrect packets into the data stream or intercepting the source
      RTCP traffic and modifying the fields.

      The replay of a session would have the effect of recreating the
      receiver feedback to the source address at a time when the source
      is not expecting additional traffic from a potentially large
      group.  The consequence of this type of attack may be less
      effective on its own, but in combination with other attacks might
      be serious.

      Eavesdropping on the session would provide an attacker with
      information on the characteristics of the source-to-receiver
      traffic, such as the frequency of RTCP traffic.  If RTCP traffic
      is unencrypted, this might also provide valuable information on
      characteristics such as group size, Media Source SSRC(s), and
      transmission characteristics of the receivers back to the source.

   b) Receiver-to-Distribution-Source Communication

      The second context is the return traffic from the group to the
      Distribution Source.  This traffic should only consist of RTCP
      packets and should include Receiver Reports, SDES information, BYE
      reports, extended reports (XR), feedback messages (RTPFB, PSFB)
      and possibly application-specific packets.  The effects of
      compromise on a single or subset of receivers are not likely to
      have as great an impact as in context (a); however, much of the
      responsibility for detecting compromise of the source data stream
      relies on the receivers.

      The effects of compromise of critical Distribution Source control
      information can be seriously amplified in the present context.  A
      large group of receivers may unwittingly generate a distributed

Top      Up      ToC       Page 45 
      DoS attack on the Distribution Source in the event that the
      integrity of the source RTCP channel has been compromised and the
      compromise is not detected by the individual receivers.

      An attacker capable of instigating a packet forgery attack could
      introduce false RTCP traffic and create fake SSRC identifiers.
      Such attacks might slow down the overall control channel data rate
      since an incorrect perception of the group size may be created.
      Similarly, the creation of fake BYE reports by an attacker would
      cause some group size instability, but should not be effective as
      long as the correct timeout rules are applied by the source in
      removing SSRC entries from its database.

      A replay attack on receiver return data to the source would have
      the same implications as the generation of false SSRC identifiers
      and RTCP traffic to the source.  Therefore, ensuring authenticity
      and freshness of the data source is important.

      Eavesdropping in this context potentially provides an attacker
      with a great deal of potentially personal information about a
      large group of receivers available from SDES packets.  It would
      also provide an attacker with information on group traffic-
      generation characteristics and parameters for calculating
      individual receiver bandwidth allowances.

   c) Receiver-to-Feedback-Target Communication

      The third context is the return traffic from the group to the
      Feedback Target.  It suffers from the same threats as the
      receiver-to-source context, with the difference being that now a
      large group of receivers may unwittingly generate a distributed
      DoS (DDos) attack on the Feedback Target, where it is impossible
      to discern if the DDoS is deliberate or due merely to a
      misconfiguration of the Feedback Target Address.  While deliberate
      attacks can be mitigated by properly authenticating messages that
      communicate the Feedback Target Address (i.e., the SDP session
      description and the Feedback Target Address sub-report block
      carried in RTCP), a misconfigured address will originate from an
      authenticated source and hence cannot be prevented using security
      mechanisms.

      Furthermore, the Feedback Target is unable to communicate its
      predicament with either the Distribution Source or the session
      receivers.  From the feedback packets received, the Feedback
      Target cannot tell either which SSM multicast group the feedback
      belongs to or the Distribution Source, making further analysis and
      suppression difficult.  The Feedback Target may not even support
      RTCP or listen on the port number in question.

Top      Up      ToC       Page 46 
      Note that because the DDoS occurs inside of the RTCP session and
      because the unicast receivers adhere to transmission interval
      calculations ([1], [10]), the bandwidth misdirected toward the
      Feedback Target in the misconfigured case will be limited to a
      percentage of the session bandwidth, i.e., the Control Traffic
      Bandwidth established for the session.

11.4.  Requirements in Each Context

   To address these threats, this section presents the security
   requirements for each context.

   a) The main threat in the source-to-receiver context concerns denial
      of service attacks through possible packet forgery.  The forgery
      may take the form of interception and modification of packets from
      the source, or it may simply inject false packets into the
      distribution channel.  To combat these attacks, data integrity and
      source authenticity MUST be applied to source traffic.  Since the
      consequences of eavesdropping do not affect the operation of the
      protocol, confidentiality is not a requirement in this context.
      However, without confidentiality, access to personal and group
      characteristics information would be unrestricted to an external
      listener.  Therefore, confidentiality is RECOMMENDED.

   b) The threats in the receiver-to-source context concern the same
      kinds of attacks, but are considered less important than the
      downstream traffic compromise.  All the security weaknesses are
      also applicable to the current RTP/RTCP security model, and
      therefore only recommendations towards protection from compromise
      are made.  Data integrity is RECOMMENDED to ensure that
      interception and modification of an individual receiver's RTCP
      traffic can be detected.  This would protect against the false
      influence of group control information and the potentially more
      serious compromise of future services provided by the distribution
      functionality.  In order to ensure security, data integrity and
      authenticity of receiver traffic is therefore also RECOMMENDED.
      With respect to data confidentiality, the same situation applies
      as in the first context, and it is RECOMMENDED that precautions be
      taken to protect the privacy of the data.

   c) The threats to the receiver-to-feedback-target context are similar
      to those in the receiver-to-source context, and thus the
      recommendations to protect against them are similar.

      However, there are a couple situations with broader issues to
      solve, which are beyond the scope of this document.

Top      Up      ToC       Page 47 
      1. An endpoint experiencing DDoS or the side effects of a
         misconfigured RTCP session may not even be a participant in the
         session, i.e., may not be listening on the respective port
         number and may even support RTCP, so it will be unable to react
         within RTCP.  Determining that there is a problem will be up to
         network administrators and, possibly, anti-malware software
         that can perform correlation across receiver nodes.

      2. With misconfiguration, unfortunately the normally desirable
         usage of SRTP and SRTCP becomes undesirable.  Because the
         packet content is encrypted, neither the misconfigured Feedback
         Target nor the network administrator have the ability to
         determine the root cause of the traffic.

      In the case where the misconfigured Feedback Target happens to be
      a node participating in the session or is an RTCP-enabled node,
      the Feedback Target Address block provides a dynamic mechanism for
      the Distribution Source to signal an alternative unicast RTCP
      feedback address to the receivers.  As this type of packet MUST be
      included in every RTCP packet originated by the Distribution
      Source, all receivers would be able to obtain the corrected
      Feedback Target information.  In this manner, receiver behavior
      should remain consistent even in the face of packet loss or when
      there are late-session arrivals.  The only caveat is that the
      misconfigured Feedback Target is largely uninvolved in the repair
      of this situation and thus relies on others for the detection of
      the problem.

   An additional security consideration, which is not a component of
   this specification but which has a direct influence upon the general
   security, is the origin of the session-initiation data.  This
   involves the SDP parameters that are communicated to the members
   prior to the start of the session via channels such as an HTTP
   server, email, SAP, or other means.  It is beyond the scope of this
   document to place any strict requirements on the external
   communication of such information; however, suitably secure SDP
   communication approaches are outlined in Section 11.7.

11.5.  Discussion of Trust Models

   As identified in the previous sections, source authenticity is a
   fundamental requirement of the protocol.  However, it is important to
   also clarify the model of trust that would be acceptable to achieve
   this requirement.  There are two fundamental models that apply in
   this instance:

Top      Up      ToC       Page 48 
   a) The shared-key model, where all authorized group members share the
      same key and can equally encrypt/decrypt the data.  This method
      assumes that an out-of-band method is applied to the distribution
      of the shared group key, ensuring that every key-holder is
      individually authorized to receive the key and, in the event of
      member departures from the group, a re-keying exercise can occur.
      The advantage of this model is that the costly processing
      associated with one-way key-authentication techniques is avoided,
      as well as the need to execute additional cipher operations with
      alternative key sets on the same data set, e.g., in the event that
      data confidentiality is also applied.  The disadvantage is that,
      for very large groups where the receiver set becomes effectively
      untrusted, a shared key does not offer much protection.

   b) The public-key authentication model, using cryptosystems such as
      RSA-based or PGP authentication, provides a more secure method of
      source authentication at the expense of generating higher
      processing overhead.  This is typically not recommended for real-
      time data streams but, in the case of RTCP reports, which are
      distributed with a minimum interval of 5 seconds, this may be a
      viable option (the processing overhead might still be too great
      for small, low-powered devices and should therefore be considered
      with caution).  Wherever possible, however, the use of public key
      source authentication is preferable to the shared key model
      identified above.

   As concerns requirements for protocol acceptability, either model is
   acceptable although it is RECOMMENDED that the more secure public-
   key-based options be applied wherever possible.

11.6.  Recommended Security Solutions

   This section presents some existing security mechanisms that are
   RECOMMENDED to suitably address the requirements outlined in Section
   11.5.  This is only intended as a guideline and it is acknowledged
   that there are other solutions that would also be suitable to comply
   with the specification.

11.6.1.  Secure Distribution of SDP Parameters

   a) SAP, HTTPS, Email -- Initial distribution of the SDP parameters
      for the session SHOULD use a secure mechanism such as the SAP
      authentication framework, which allows an authentication
      certificate to be attached to the session announcements.  Other
      methods might involve HTTPS or signed email content from a trusted
      source.  However, some more commonly used techniques for
      distributing session information and starting media streams are
      the Real-Time Streaming Protocol (RTSP) [25] and SIP [14].

Top      Up      ToC       Page 49 
   b) RTSP -- RTSP provides a client- or server-initiated stream control
      mechanism for real-time multimedia streams.  The session
      parameters are conveyed using SDP syntax and may adopt standard
      HTTP authentication mechanisms in combination with suitable
      network (e.g., IPsec)- or transport (e.g., Transport Layer
      Security (TLS))-level security.

   c) SIP -- A typical use of SIP involving a unicast feedback
      identifier might be a client wishing to dynamically join a multi-
      party call on a multicast address using unicast RTCP feedback.
      The client would be required to authenticate the SDP session
      descriptor information returned by the SIP server.  The
      recommended method for this, as outlined in the SIP specification
      [14], is to use an S/MIME message body containing the session
      parameters signed with an acceptable certificate.

   For the purposes of this profile, it is acceptable to use any
   suitably secure authentication mechanism that establishes the
   identity and integrity of the information provided to the client.

11.6.2.  Suitable Security Solutions for RTP Sessions with Unicast
         Feedback

   a) SRTP -- SRTP [3] is the recommended Audio/Video Transport (AVT)
      security framework for RTP sessions.  It specifies the general
      packet formats and cipher operations that are used and provides
      the flexibility to select different stream ciphers based on
      preference/requirements.  It can provide confidentiality of the
      RTP and RTCP packets as well as protection against integrity
      compromise and replay attacks.  It provides authentication of the
      data stream using the shared-key trust model.  Any suitable key-
      distribution mechanism can be used in parallel to the SRTP
      streams.

   b) IPSEC -- A more general group security profile that might be used
      is the Group Domain of Interpretation [23], which defines the
      process of applying IPSec mechanisms to multicast groups.  This
      requires the use of the Encapsulating Security Payload (ESP) in
      tunnel mode as the framework and it provides the capability to
      authenticate -- either using a shared key or individually through
      public-key mechanisms.  It should be noted that using IPSec would
      break the 'transport-independent' condition of RTP and would
      therefore not be useable for anything other than IP-based
      communication.

   c) TESLA - Timed Efficient Stream Loss-Tolerant Authentication
      (TESLA) [24] is a scheme that provides a more flexible approach to
      data authentication using time-based key disclosure.  The

Top      Up      ToC       Page 50 
      authentication uses one-way, pseudo-random key functions based on
      key chain hashes that have a short period of authenticity based on
      the key disclosure intervals from the source.  As long as the
      receiver can ensure that the encrypted packet is received prior to
      the key disclosure by the source, which requires loose time
      synchronization between source and receivers, it can prove the
      authenticity of the packet.  The scheme does introduce a delay
      into the packet distribution/decryption phase due to the key
      disclosure delay; however, the processing overhead is much lower
      than other standard public-key mechanisms and therefore may be
      more suited to small or energy-restricted devices.

11.6.3.  Secure Key Distribution Mechanisms

   a) MIKEY -- Multimedia Internet KEYing (MIKEY) [29] is the preferred
      solution for SRTP sessions providing a shared group-key
      distribution mechanism and intra-session rekeying facilities.  If
      a partly protected communication channel exists, keys may also be
      conveyed using SDP as per [27].

   b) GSAKMP -- The Group Secure Association Key Management Protocol
      (GSAKMP) is the general solution favored for Multicast Secure
      group-key distribution.  It is the recommended key distribution
      solution for Group Domain of Interpretation (GDOI) [RFC3547]
      sessions.

11.7.  Troubleshooting Misconfiguration

   As noted above, the security mechanisms in place will not help in
   case an authorized source spreads properly authenticated and
   integrity-protected yet incorrect information about the Feedback
   Target.  In this case, the accidentally communicated Feedback Target
   will receive RTCP packets from a potentially large group of receivers
   -- the RTCP rate fortunately limited by the RTCP timing rules.

   Yet, the RTCP packets do not provide much context information and, if
   encrypted, do not provide any context, making it difficult for the
   entity running (the network with) the Feedback Target to debug and
   correct this problem, e.g., by tracking down and informing the origin
   of the misconfiguration.

   One suitable approach may be to provide explicit context information
   in RTCP packets that would allow determining the source.  While such
   an RTCP packet could be defined in this specification, it would be of
   no use when using SRTP/SRTCP and encryption of RTCP reports.
   Therefore, and because the extensions in this document may not be the

Top      Up      ToC       Page 51 
   only case that may face such a problem, it is desirable to find a
   solution that is applicable to RTP at large.  Such mechanisms are for
   further study in the AVT WG.

12.  Backwards Compatibility

   The use of unicast feedback to the source should not present any
   serious backwards compatibility issues.  The RTP data streams should
   remain unaffected, as should the RTCP packets from the Media
   Sender(s) that continue to enable inter-stream synchronization in the
   case of multiple streams.  The unicast transmission of RTCP data to a
   source that does not have the ability to redistribute the traffic
   either by simple reflection or through summaries could have serious
   security implications, as outlined in Section 11, but would not
   actually break the operation of RTP.  For RTP-compliant receivers
   that do not understand the unicast mechanisms, the RTCP traffic may
   still reach the group in the event that an ASM distribution network
   is used, in which case there may be some duplication of traffic due
   to the reflection channel, but this should be ignored.  It is
   anticipated, however, that typically the distribution network will
   not enable the receiver to multicast RTCP traffic, in which case the
   data will be lost and the RTCP calculations will not include those
   receivers.  It is RECOMMENDED that any session that may involve non-
   unicast-capable clients should always use the simple packet-
   reflection mechanism to ensure that the packets received can be
   understood by all clients.

13.  IANA Considerations

   The following contact information shall be used for all registrations
   included here:

     Contact:      Joerg Ott
                   mail: jo@acm.org
                   tel:  +358-9-470-22460

   Based on the guidelines suggested in [2], a new RTCP packet format
   has been registered with the RTCP Control Packet type (PT) Registry:

     Name:           RSI
     Long name:      Receiver Summary Information
     Value:          209
     Reference:      This document.

   This document defines a substructure for RTCP RSI packets.  A new
   sub-registry has been set up for the sub-report block type (SRBT)
   values for the RSI packet, with the following registrations created
   initially:

Top      Up      ToC       Page 52 
      Name:           IPv4 Address
      Long name:      IPv4 Feedback Target Address
      Value:          0
      Reference:      This document.

      Name:           IPv6 Address
      Long name:      IPv6 Feedback Target Address
      Value:          1
      Reference:      This document.

      Name:           DNS Name
      Long name:      DNS Name indicating Feedback Target Address
      Value:          2
      Reference:      This document.

      Name:           Loss
      Long name:      Loss distribution
      Value:          4
      Reference:      This document.

      Name:           Jitter
      Long name:      Jitter Distribution
      Value:          5
      Reference:      This document.

      Name:           RTT
      Long name:      Round-trip time distribution
      Value:          6
      Reference:      This document.

      Name:           Cumulative loss
      Long name:      Cumulative loss distribution
      Value:          7
      Reference:      This document.

      Name:           Collisions
      Long name:      SSRC Collision list
      Value:          8
      Reference:      This document.

      Name:           Stats
      Long name:      General statistics
      Value:          10
      Reference:      This document.

Top      Up      ToC       Page 53 
      Name:           RTCP BW
      Long name:      RTCP Bandwidth indication
      Value:          11
      Reference:      This document.

      Name:           Group Info
      Long name:      RTCP Group and Average Packet size
      Value:          12
      Reference:      This document.

      The value 3 shall be reserved as a further way of specifying a
      Feedback Target Address.  The value 3 MUST only be allocated for a
      use defined in an IETF Standards Track document.

      Further values may be registered on a first come, first served
      basis.  For each new registration, it is mandatory that a
      permanent, stable, and publicly accessible document exists that
      specifies the semantics of the registered parameter as well as the
      syntax and semantics of the associated sub-report block.  The
      general registration procedures of [5] apply.

   In the registry for SDP parameters, the attribute named "rtcp-
   unicast" has been registered as follows:

   SDP Attribute ("att-field"):

     Attribute Name:     rtcp-unicast
     Long form:          RTCP Unicast feedback address
     Type of name:       att-field
     Type of attribute:  Media level only
     Subject to charset: No
     Purpose:            RFC 5760
     Reference:          RFC 5760
     Values:             See this document.

14.  References

14.1.  Normative References

   [1]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications", STD 64,
        RFC 3550, July 2003.

   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

Top      Up      ToC       Page 54 
   [3]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
        Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
        3711, March 2004.

   [4]  Quinn, B. and R. Finlayson, "Session Description Protocol (SDP)
        Source Filters", RFC 4570, July 2006.

   [5]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
        Description Protocol", RFC 4566, July 2006.

   [6]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
        Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

   [7]  Huitema, C., "Real Time Control Protocol (RTCP) attribute in
        Session Description Protocol (SDP)", RFC 3605, October 2003.

   [8]  Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific
        Protocol Independent Multicast in 232/8", BCP 120, RFC 4608,
        August 2006.

   [9]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group
        Management Protocol Version 3 (IGMPv3) and Multicast Listener
        Discovery Protocol Version 2 (MLDv2) for Source-Specific
        Multicast", RFC 4604, August 2006.

   [10] Casner, S., "Session Description Protocol (SDP) Bandwidth
        Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
        July 2003.

   [11] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
        63, RFC 3629, November 2003.

   [12] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media
        Attributes in the Session Description Protocol (SDP)", RFC 5576,
        June 2009.

   [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

14.2.  Informative References

   [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [15] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
        "Extended RTP Profile for Real-time Transport Control Protocol
        (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.

Top      Up      ToC       Page 55 
   [16] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work
        in Progress, October 2003.

   [17] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
        "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
        Specification (Revised)", RFC 4601, August 2006.

   [18] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent
        Multicast - Dense Mode (PIM-DM): Protocol Specification
        (Revised)", RFC 3973, January 2005.

   [19] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol
        Extensions for BGP-4", RFC 4760, January 2007.

   [20] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery
        Protocol (MSDP)", RFC 3618, October 2003.

   [21] Session Directory Rendez-vous (SDR), developed at University
        College London by Mark Handley and the Multimedia Research
        Group, http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/.

   [22] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
        Protocol", RFC 2974, October 2000.

   [23] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
        Domain of Interpretation", RFC 3547, July 2003.

   [24] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe,
        "Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
        Multicast Source Authentication Transform Introduction", RFC
        4082, June 2005.

   [25] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
        Protocol (RTSP)", RFC 2326, April 1998.

   [26] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP
        Control Protocol Extended Reports (RTCP XR)", RFC 3611, November
        2003.

   [27] Andreasen, F., Baugher, M., and D. Wing, "Session Description
        Protocol (SDP) Security Descriptions for Media Streams", RFC
        4568, July 2006.

   [28] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-
        time Transport Control Protocol (RTCP)-Based Feedback
        (RTP/SAVPF)", RFC 5124, February 2008.

Top      Up      ToC       Page 56 
   [29] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
        Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August
        2004.

Top      Up      ToC       Page 57 
Appendix A.  Examples for Sender-Side Configurations

   This appendix describes a few common setups, focusing on the
   contribution side, i.e., the communications between the Media
   Sender(s) and the Distribution Source.  In all cases, the same
   session description may be used for the distribution side as defined
   in the main part of this document.  This is because this
   specification defines only the media stream setup between the
   Distribution Source and the receivers.

A.1.  One Media Sender Identical to the Distribution Source

   In the simplest case, the Distribution Source is identical to the
   Media Sender as depicted in Figure 3.  Obviously, no further
   configuration for the interaction between the Media Sender and the
   Distribution Source is necessary.

                          Source-specific
         +--------+          Multicast
         |        |     +----------------> R(1)
         |M   D S |     |                    |
         |E   I O |  +--+                    |
         |D   S U |  |  |                    |
         |I   T R |  |  +-----------> R(2)   |
         |A   R C |->+-----  :          |    |
         |  = I E |  |  +------> R(n-1) |    |
         |S   B   |  |  |          |    |    |
         |E   U   |  +--+--> R(n)  |    |    |
         |N   T   |          |     |    |    |
         |D   I   |<---------+     |    |    |
         |E   O   |<---------------+    |    |
         |R   N   |<--------------------+    |
         |        |<-------------------------+
         +--------+            Unicast

     Figure 3: Media Source == Distribution Source

A.2.  One Media Sender

   In a slightly more complex scenario, the Media Sender and the
   Distribution Source are separate entities running on the same or
   different machines.  Hence, the Media Sender needs to deliver the
   media stream(s) to the Distribution Source.  This can be done either
   via unicasting the RTP stream, via ASM multicast, or via SSM.  In
   this case, the Distribution Source is responsible for forwarding the
   RTP packets comprising the media stream and the RTCP Sender Reports
   towards the receivers and conveying feedback from the receivers, as
   well as from itself, to the Media Sender.

Top      Up      ToC       Page 58 
   This scenario is depicted in Figure 4.  The communication setup
   between the Media Sender and the Distribution Source may be
   statically configured or SDP may be used in conjunction with some
   signaling protocol to convey the session parameters.  Note that it is
   a local configuration matter of the Distribution Source how to
   associate a session between the Media Sender and itself (the
   Contribution session) with the corresponding session between itself
   and the receivers (the Distribution session).

                                      Source-specific
                        +-----+          Multicast
                        |     |     +----------------> R(1)
                        | D S |     |                    |
                        | I O |  +--+                    |
                        | S U |  |  |                    |
        +--------+      | T R |  |  +-----------> R(2)   |
        | Media  |<---->| R C |->+-----  :          |    |
        | Sender |      | I E |  |  +------> R(n-1) |    |
        +--------+      | B   |  |  |          |    |    |
                        | U   |  +--+--> R(n)  |    |    |
                        | T   |          |     |    |    |
                        | I   |<---------+     |    |    |
                        | O   |<---------------+    |    |
                        | N   |<--------------------+    |
                        |     |<-------------------------+
                        +-----+            Unicast

           Contribution               Distribution
             Session                    Session
         (unicast or ASM)                 (SSM)

     Figure 4: One Media Sender Separate from Distribution Source

A.3.  Three Media Senders, Unicast Contribution

   Similar considerations apply if three Media Senders transmit to an
   SSM multicast group via the Distribution Source and individually send
   their media stream RTP packets via unicast to the Distribution
   Source.

   In this case, the responsibilities of the Distribution Source are a
   superset to the previous case; the Distribution Source also needs to
   relay media traffic from each Media Sender to the receivers and to
   forward (aggregated) feedback from the receivers to the Media
   Senders.  In addition, the Distribution Source relays RTCP packets
   (SRs) from each Media Sender to the other two.

Top      Up      ToC       Page 59 
   The configuration of the Media Senders is identical to the previous
   case.  It is just the Distribution Source that must be aware that
   there are multiple senders and then perform the necessary relaying.
   The transport address for the RTP session at the Distribution Source
   may be identical for all Media Senders (which may make correlation
   easier) or different addresses may be used.

   This setup is depicted in Figure 5.

                                   Source-specific
                     +-----+          Multicast
     +--------+      |     |     +----------------> R(1)
     | Media  |<---->| D S |     |                    |
     |Sender 1|      | I O |  +--+                    |
     +--------+      | S U |  |  |                    |
                     | T R |  |  +-----------> R(2)   |
     +--------+      | R C |->+-----  :          |    |
     | Media  |<---->| I E |  |  +------> R(n-1) |    |
     |Sender 2|      | B   |  |  |          |    |    |
     +--------+      | U   |  +--+--> R(n)  |    |    |
                     | T   |          |     |    |    |
     +--------+      | I   |<---------+     |    |    |
     | Media  |<---->| O   |<---------------+    |    |
     |Sender 3|      | N   |<--------------------+    |
     +--------+      |     |<-------------------------+
                     +-----+            Unicast

           Contribution               Distribution
             Session                    Session
            (unicast)                    (SSM)

     Figure 5: Three Media Senders, Unicast Contribution

A.4.  Three Media Senders, ASM Contribution Group

   In this final example, the individual unicast contribution sessions
   between the Media Senders and the Distribution Source are replaced by
   a single ASM contribution group (i.e., a single common RTP session).
   Consequently, all Media Senders receive each other's traffic by means
   of IP-layer multicast and the Distribution Source no longer needs to
   perform explicit forwarding between the Media Senders.  Of course,
   the Distribution Source still forwards feedback information received
   from the receivers (optionally as summaries) to the ASM contribution
   group.

Top      Up      ToC       Page 60 
   The ASM contribution group may be statically configured or the
   necessary information can be communicated using a standard SDP
   session description for a multicast session.  Again, it is up to the
   implementation of the Distribution Source to properly associate the
   ASM contribution session and the SSM distribution sessions.

   Figure 6 shows this scenario.

                    _                   Source-specific
                   / \    +-----+          Multicast
     +--------+   |   |   |     |     +----------------> R(1)
     | Media  |<->| A |   | D S |     |                    |
     |Sender 1|   | S |   | I O |  +--+                    |
     +--------+   | M |   | S U |  |  |                    |
                  |   |   | T R |  |  +-----------> R(2)   |
     +--------+   | G |   | R C |->+-----  :          |    |
     | Media  |<->| r |<->| I E |  |  +------> R(n-1) |    |
     |Sender 2|   | o |   | B   |  |  |          |    |    |
     +--------+   | u |   | U   |  +--+--> R(n)  |    |    |
                  | p |   | T   |          |     |    |    |
     +--------+   |   |   | I   |<---------+     |    |    |
     | Media  |<->|   |   | O   |<---------------+    |    |
     |Sender 3|    \_/    | N   |<--------------------+    |
     +--------+           |     |<-------------------------+
                          +-----+            Unicast

              Contribution            Distribution
                Session                  Session
                 (ASM)                   (SSM)

           Figure 6: Three Media Senders in ASM Group

Appendix B.  Distribution Report Processing at the Receiver

B.1.  Algorithm

   Example processing of Loss Distribution Values

   X values represent the loss percentage.
   Y values represent the number of receivers.

   Number of x values is the NDB value

   xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV)

Top      Up      ToC       Page 61 
   First data point = MnDV,first ydata

   then

   For each ydata => xdata += (MnDV + (xrange / NDB))

B.2.  Pseudo-Code

   Packet Variables -> factor,NDB,MnDVL,MaDV
   Code variables -> xrange, ydata[NDB],x,y

   xrange = MaDV - MnDV
   x = MnDV;

   for(i=0; i<NDB; i++) {
        y = (ydata[i] * factor);
        /*OUTPUT x and y values*/
        x += (xrange / NDB);
   }

B.3.  Application Uses and Scenarios

   Providing a distribution function in a feedback message has a number
   of uses for different types of applications.  Although this appendix
   enumerates potential uses for the distribution scheme, it is
   anticipated that future applications might benefit from it in ways
   not addressed in this document.  Due to the flexible nature of the
   summarization format, future extensions may easily be added.  Some of
   the scenarios addressed in this section envisage potential uses
   beyond a simple SSM architecture, for example, single-source group
   topologies where every receiver may in fact also be capable of
   becoming the source.  Another example may be multiple SSM topologies,
   which, when combined, make up a larger distribution tree.

   A distribution of values is useful as input into any algorithm,
   multicast or otherwise, that could be optimized or tuned as a result
   of having access to the feedback values for all group members.
   Following is a list of example areas that might benefit from
   distribution information:

   - The parameterization of a multicast Forward Error Correction (FEC)
     algorithm.  Given an accurate estimate of the distribution of
     reported losses, a source or other distribution agent that does not
     have a global view would be able to tune the degree of redundancy
     built into the FEC stream.  The distribution might help to identify
     whether the majority of the group is experiencing high levels of
     loss, or whether in fact the high loss reports are only from a
     small subset of the group.  Similarly, this data might enable a

Top      Up      ToC       Page 62 
     receiver to make a more informed decision about whether it should
     leave a group that includes a very high percentage of the worst-
     case reporters.

   - The organization of a multicast data stream into useful layers for
     layered coding schemes.  The distribution of packet losses and
     delay would help to identify what percentage of members experience
     various loss and delay levels, and thus how the data stream
     bandwidth might be partitioned to suit the group conditions.  This
     would require the same algorithm to be used by both senders and
     receivers in order to derive the same results.

   - The establishment of a suitable feedback threshold.  An application
     might be interested to generate feedback values when above (or
     below) a particular threshold.  However, determining an appropriate
     threshold may be difficult when the range and distribution of
     feedback values is not known a priori.  In a very large group,
     knowing the distribution of feedback values would allow a
     reasonable threshold value to be established, and in turn would
     have the potential to prevent message implosion if many group
     members share the same feedback value.  A typical application might
     include a sensor network that gauges temperature or some other
     natural phenomenon.  Another example is a network of mobile devices
     interested in tracking signal power to assist with hand-off to a
     different distribution device when power becomes too low.

   - The tuning of Suppression algorithms.  Having access to the
     distribution of round-trip times, bandwidth, and network loss would
     allow optimization of wake-up timers and proper adjustment of the
     Suppression interval bounds.  In addition, biased wake-up functions
     could be created not only to favor the early response from more
     capable group members but also to smooth out responses from
     subsequent respondents and to avoid bursty response traffic.

   - Leader election among a group of processes based on the maximum or
     minimum of some attribute value.  Knowledge of the distribution of
     values would allow a group of processes to select a leader process
     or processes to act on behalf of the group.  Leader election can
     promote scalability when group sizes become extremely large.

B.4.  Distribution Sub-Report Creation at the Source

   The following example demonstrates two different ways to convey loss
   data using the generic format of a Loss sub-report block (Section
   7.1.4).  The same techniques could also be applied to representing
   other distribution types.

Top      Up      ToC       Page 63 
   1) The first method attempts to represent the data in as few bytes as
      possible.

   2) The second method conveys all values without providing any savings
      in bandwidth.

   Data Set
   X values indicate loss percentage reported; Y values indicate the
   number of receivers reporting that loss percentage.

      X -  0  |  1  | 2 |  3   |   4  |  5   |  6   |  7   |  8  |  9
      Y - 1000| 800 | 6 | 1800 | 2600 | 3120 | 2300 | 1100 | 200 | 103

      X - 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19
      Y - 74 | 21 | 30 | 65 | 60 | 80 |  6 |  7 |  4 |  5

      X - 20 | 21 | 22  |  23  |  24  | 25  | 26  | 27  | 28  | 29
      Y - 2  | 10 | 870 | 2300 | 1162 | 270 | 234 | 211 | 196 | 205

      X - 30  | 31  | 32  | 33 | 34 | 35 | 36 | 37 | 38 | 39
      Y - 163 | 174 | 103 | 94 | 76 | 52 | 68 | 79 | 42 | 4

   Constant value
   Due to the size of the multiplicative factor field being 4 bits, the
   maximum multiplicative value is 15.

   The distribution type field of this packet would be value 1 since it
   represents loss data.

   Example: 1st Method

      Description
      The minimal method of conveying data, i.e., small amount of bytes
      used to convey the values.

      Algorithm
      Attempt to fit the data set into a small sub-report size, selected
      length of 8 octets

      Can we split the range (0 - 39) into 16 4-bit values?  The largest
      bucket value would, in this case, be the bucket for X values 5 -
      7.5, the sum of which is 5970.  An MF value of 9 will generate a
      multiplicative factor of 2^9, or 512 -- which, multiplied by the
      max bucket value, produces a maximum real value of 7680.

Top      Up      ToC       Page 64 
      The packet fields will contain the values:

      Header distribution Block
      Distribution Type:                       1
      Number of Data Buckets:                  16
      Multiplicative Factor:                   9
      Packet Length field:                     5 (5 * 4 => 20 bytes)
      Minimum Data Value:                      0
      Maximum Data Value:                      39
      Data Bucket values:                      (each value is 16-bits)

      Results, 4-bit buckets:

         X - 0 - 2.5 | 2.5 - 5 | 5 - 7.5 | 7.5 - 10
        (Y -   1803  |   4403  |   5970  |   853 )  ACTUAL
         Y -    4    |    9    |    12   |    2

         X - 10 - 12.5 | 12.5 - 15 | 15 - 17.5 | 17.5 - 20
        (Y -     110   |    140    |    89.5   |    12.5)  ACTUAL
         Y -      0    |     0     |     0     |      0

         X - 20 - 22.5 | 22.5 - 25 | 25 - 27.5 | 27.5 - 30
        (Y -    447    |    3897   |    609.5  |   506.5)  ACTUAL
         Y -     1     |     8     |      1    |     1

         X - 30 - 32.5 | 32.5 - 35 | 35 - 37.5 | 37.5 - 40
        (Y -   388.5   |    221.5  |   159.5   |    85.5)  ACTUAL
         Y -    1      |      0    |     0     |     0

   Example: 2nd Method

      Description
      This demonstrates the most accurate method for representing the
      data set.  This method doesn't attempt to optimise any values.

      Algorithm
      Identify the highest value and select buckets large enough to
      convey the exact values, i.e., no multiplicative factor.

      The highest value is 3120.  This requires 12 bits (closest 2 bit
      boundary) to represent, therefore it will use 60 bytes to
      represent the entire distribution.  This is within the max packet
      size; therefore, all data will fit within one sub-report block.
      The multiplicative value will be 1.

Top      Up      ToC       Page 65 
      The packet fields will contain the values:

      Header Distribution Block
      Distribution Type:                        1
      Number of Data Buckets:                   40
      Multiplicative Factor:                    0
      Packet Length field:                      18 (18 * 4 => 72 bytes)
      Minimum Loss Value:                       0
      Maximum Loss Value:                       39

      Bucket values are the same as the initial data set.

      Result
      Selecting one of the three methods outlined above might be done by
      a congestion parameter or by user preference.  The overhead
      associated with processing the packets is likely to differ very
      little between the techniques.  The savings in bandwidth are
      apparent, however, using 20, 52, and 72 octets respectively.
      These values would vary more widely for a larger data set with
      less correlation between results.

Acknowledgements

   The authors would like to thank Magnus Westerlund, Dave Oran, Tom
   Taylor, and Colin Perkins for detailed reviews and valuable comments.

Top      Up      ToC       Page 66 
Authors' Addresses

   Joerg Ott
   Aalto University
   School of Science and Technology
   Department of Communications and Networking
   PO Box 13000
   FIN-00076 Aalto

   EMail: jo@acm.org


   Julian Chesterfield
   University of Cambridge
   Computer Laboratory,
   15 JJ Thompson Avenue
   Cambridge
   CB3 0FD
   UK

   EMail: julianchesterfield@cantab.net


   Eve Schooler
   Intel Research / CTL
   MS RNB6-61
   2200 Mission College Blvd.
   Santa Clara, CA, USA 95054-1537

   EMail: eve_schooler@acm.org