J.Chesterfield 
                                                             E.Schooler 
                                                   AT&T Labs - Research 
   Internet Draft                                                 J.Ott 
   Document: draft-ietf-avt-rtcpssm-00   Tellique Kommunikationstechnik  
                                                                   GmbH 
   Expires: August 2002                                   February 2002 
 
           RTCP Extensions for Single-Source Multicast Sessions  
                           with Unicast Feedback 
    
 
Status of this Memo 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet- Drafts as 
   reference material or to cite them other than as work in progress. 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
    
Abstract 
   This document specifies a modification to the Real-time Transport 
   Control Protocol (RTCP) to use unicast feedback. 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 possible or 
   not preferred. In addition, it can be applied to any group that 
   might benefit from a sender controlled summarised reporting 
   mechanism.  
    
    
1. Conventions and Acronyms 
   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 
   document, are to be interpreted as described in RFC 2119. 
    
     
   Chesterfield     Internet Draft - Expires 2002            [Page 1] 
                        RTCP with Unicast Feedback 
    
 
2. Introduction 
   The Real-time Transport Protocol (RTP) [1] provides a real-time 
   transport mechanism suitable for unicast or Internet Standard 
   multicast communication between multimedia applications. Typical 
   uses are for real-time or near real-time group communication via 
   audio and video data streams. An important component of the RTP 
   protocol is the control channel, defined as the Real-Time Control 
   Protocol (RTCP). RTCP involves the periodic transmission of control 
   packets between group members in a session, enabling the 
   distribution or calculation of session specific information such as 
   packet loss and round trip time to other hosts, and group size 
   estimation. 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 a unicast mode or in the traditional   
   multicast mode of Any Source Multicast (ASM) group communication, 
   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. Typical routing protocols that enable such   
   communication are the Distance Vector Multicast Routing Protocol 
   (DVMRP) [2] or Protocol Independent Multicast (PIM) [3][4] in 
   combination with an Inter-domain routing protocol such as Multicast 
   Border Gateway Protocol (MBGP) [5] with Multicast Source Discovery 
   (MSDP) [6]. Such routing protocols enable a host to join a single 
   multicast group address and to send to or to receive data from all 
   members in the group with no prior knowledge of the membership. In 
   order to enable such a service in the network, however there is a 
   great deal of complexity involved at the routing level. 
    
   An alternative approach has been developed for multicast groups with 
   just a single sender. The Source Specific Multicast (SSM) [7] model 
   has the advantage of removing a great deal of the routing complexity 
   involved in multicast group creation and source information 
   distribution. The disadvantage of SSM, with respect to real-time 
   traffic using RTP, is that the simplification to the routing 
   protocols removes the ability for any member of the group to 
   communicate with any other member of the group without an explicit 
   join to that host.  
    
   The solution proposed in this draft defines a new method for 
   distributing control information amongst all members in a multicast 
   session and is designed to operate under any multicast group 
   communication scenario. It is, however, of particular benefit to SSM 
   sessions in the absence of receivers being able to communicate with 
   each other directly. The RTP data stream protocol itself is 
   unaffected. The basic architectural models to which this feedback 
   method could apply include: 
    
   a) SSM groups with a single sender.  
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 2] 
                        RTCP with Unicast Feedback 
    
      This is the main motivation behind the unicast RTCP feedback 
      mechanism. The proposed extensions allow SSM groups that do not 
      have many-to-many communication capability to still receive RTP 
      data streams and to continue to participate in the RTP control 
      protocol, RTCP. Because SSM adopts the notion of a sender data 
      channel that provides a one-to-many communication facility from 
      the source to all the receivers in the group, the RTCP feedback 
      is unicast to the source on the standard RTCP port. 
    
   b) One-to-many broadcast networks.  
      An example of such a network is a satellite network with a 
      terrestrial low-bandwidth return channel or a broadband cable 
      link. This architecture differs very little from the  SSM channel 
      concept, but is likely to require a translator of some kind to 
      render the RTP data stream onto the satellite or cable 
      distribution channel. 
    
   c) ASM with a single sender.  
      An SDP session announcement type may identify a session as having 
      a single sender receiving unicast RTCP feedback. Receivers join 
      the multicast group address and receive RTP and RTCP data from 
      the source on the specified address/port combinations. The RTCP 
      feedback is unicast back to the source on the RTCP port. This 
      model is not more efficient than a standard multicast group RTP 
      communication scenario, and is therefore not recommended to 
      replace the traditional mechanism. However it may be help to 
      prevent overtaxing multicast routing infrastructure that does not 
      scale as efficiently. 
    
   SSM sessions are typically assigned a value in the group address 
   range 232.0.0.0 through 232.255.255.255, although this is not a 
   requirement. A session may be assigned any valid multicast address, 
   as long as the local network is configured to allow source specific 
   joins outside the suggested SSM range. In order for a host to 
   receive traffic from an SSM capable source, it must support the 
   IGMPv3 multicast group membership reporting protocol, which enables 
   the host to explicitly request traffic from a (source,group) pair. 
   An SDP syntax is defined in Section 10 to specify the mode of 
   operation for the session and the session characteristics such as 
   the (source, group) identifier and feedback address. 
    
   The modifications proposed in this document are intended to 
   supplement the existing RTCP feedback mechanisms described in [1], 
   Section 6. For certain distribution networks, such as SSM networks, 
   this may be a requirement, whereas in others it is an optional 
   feature that may be used. 
    
    
3. Basic Operation 
   This draft proposes two new methods to enable receiver feedback to 
   all members in a session. Each involves the unicasting of RTCP 
   packets to a source whose job it is to re-distribute the information 
   to the members of the group. The source must always be able to 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 3] 
                        RTCP with Unicast Feedback 
    
   communicate with all group members in order for either mechanism to 
   work. 
    
   The first method, the 'Simple Feedback Model', is a basic mechanism 
   whereby all Receiver Reports are unicast to the source and 
   subsequently forwarded by the 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 Receiver Reports to a multicast 
   address, a receiver uses a unicast address and still receives RTCP 
   traffic in the usual manner. This method also has the advantage of 
   being backwards compatible with RTP/RTCP implementations that do not 
   support unicast feedback to the source and operate using the 
   standard multicast group communication model, ASM. In a session that 
   is using ASM, such a receiver would multicast Receiver Reports to 
   the group address and port+1 as stated in [1]. This would still be 
   received by all receivers. In a session using SSM, the network 
   prevents any data from the receiver being distributed further than 
   the first hop router. Additionally, any data heard from this 
   receiver by other hosts on the same subnet should be filtered out by 
   the host IP stack and therefore will not cause any problems with 
   respect to the calculation of Receiver RTCP bandwidth since this 
   receiver will not be heard by any other members. 
    
   The second method, the 'Sender Feedback Summary Model' is a 
   summarised reporting scheme that provides savings in bandwidth by 
   consolidating all the Receiver Reports into one summary packet that 
   is then distributed to all the receivers. The advantage of this 
   scheme is apparent for large group sessions where the basic 
   forwarding mechanism outlined above would create a large amount of 
   packet replication in order to forward all the information to all 
   the receivers. The basic operation of the scheme is the same as the 
   first method, however it requires that all the members in the 
   session understand the new summarised packet format outlined in 
   Section 7.1. Additionally, the summarised scheme provides a generic 
   mechanism for sending distribution information about the data 
   reported by the whole group. Potential uses for this are addressed 
   in Section 7.4.  
    
   To differentiate between the two reporting mechanisms, a new SDP 
   identifier is created and discussed in Section 10. The method of 
   reporting must be decided prior to the start of the session, a 
   distribution source may not change the method during a session. 
    
    
4. Definitions 
   Distribution Source: In order for unicast feedback to work, there 
   must only be one session distribution source for any subset of 
   receivers to which RTCP feedback is directed. Heterogeneous        
   networks comprised of ASM multiple sender groups, unicast-only 
   clients and/or SSM single-sender receiver groups may be       
   connected via translators or mixers (see Section 9 for details) to 
   create a single source group. In order for unicast feedback to work, 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 4] 
                        RTCP with Unicast Feedback 
    
   only one source must be responsible for distributing the RTP stream 
   and for forwarding RTCP information to all receivers. That source is 
   called the distribution source. 
                 
   RTP and RTCP Channels: The data distributed from the source to the   
   receivers is referred to as the RTP and RTCP channels. These 
   channels are differentiated via the port numbers as [port] and [port 
   + 1] for RTP and RTCP respectively. See [1] for further explanation 
   of the port numbering for these channels. 
    
   Unicast RTCP Feedback Target: For a session defined as having a 
   distribution source A, on ports n and n+1, the unicast RTCP feedback 
   target is the IP address of Source A on port n+1 unless otherwise 
   stated in the SDP setup information. See Section 10 for details on 
   how the address is specified. 
             
   SSRC: Synchronization source. A 32-bit value that uniquely 
   identifies each member in a session. See [1] for further 
   information. 
       
   Report blocks: In RTCP [1], it is encouraged to stack multiple 
   report blocks in Sender and Receiver Report packets. In this way, a 
   variable size packet is created that can include information from 
   one source pertaining to multiple sources in the group. The concept 
   of report blocks is extended in this draft to encompass Generic 
   Summary Report packets in which a source can optionally stack 
   multiple reports into one packet in order to provide additional 
   feedback on the RTCP traffic received from the group. 
    
    
5. Packet types 
   The RTCP packet types defined in [1] are: 
    
   type       description              Payload number 
   SR         sender report            200 
   RR         receiver report          201 
   SDES       source description       202 
   BYE        goodbye                  203 
   APP        application-defined      204 
    
   These remain unmodified. Later profile extensions may be added to 
   these which are not covered in [1] or this document. In addition to 
   the existing types, two new packet types are introduced. Further 
   information on each of these is provided in this draft.  
    
   The new packet types are: 
         
   type       description                    Payload number 
   RSI        Receiver Summary Information   [see Section 12] 
   GSR        General Summary Report         [see Section 12] 
    
   Within the General Summary Report packet, various types of 
   distribution data may be reported, each of which requires a 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 5] 
                        RTCP with Unicast Feedback 
    
   distribution type identifier. Current types addressed in this 
   document are: 
    
   Distribution Type            Number 
   Packet Loss                  1 
   Receiver Jitter              2 
   Round Trip Time estimation   3 
   SSRC distribution            4 
    
    
6. Simple feedback model 
6.1 Packet Formats 
   For this mechanism, the packet types used remain the same as for 
   standard RTCP feedback in [1]. Receivers still generate Receiver 
   Reports with information on the quality of the stream received from 
   the source. The distribution source still must create Sender Reports 
   that include timestamp information for stream synchronisation and 
   round trip time calculation. Both the 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 behaviour 
   For the simple feedback model, the source provides a simple packet 
   reflection mechanism. It is the default behaviour for any 
   distribution source and is the minimum requirement for acting as a 
   source to a group of receivers using unicast RTCP feedback.  
         
   The source may not stack report blocks received from different SSRCs 
   into one packet for retransmission to the group. Every RTCP packet 
   from each receiver must be reflected individually. 
         
   The source must listen for unicast RTCP data sent to the RTCP port. 
   All unicast data received on this port must be forwarded to the 
   group on the multicast RTCP channel. Any multicast data received on    
   this port must not be forwarded but processed as defined in [1]. 
         
   The reflected traffic should not be included in the transmission 
   interval calculation by the source. In other words, the source 
   should not consider reflected packets as part of it's own control 
   data bandwidth allowance. The algorithm for computing the allowance 
   is explained in Section 9. The control bandwidth traffic included in 
   the calculation includes any Sender reports to the group, along with 
   any additional SDES and APP packets. 
       
   If an application wishes to use APP packets, it is recommended that 
   the 'Simple Feedback Model' be used since it is likely that all 
   receivers in the session will need to hear the APP specific packets. 
   The same applies for all other future RTCP packets that are not 
   defined in the base RTP specification [1]. This decision must be 
   made in advance of the session and indicated in the SDP 
   announcement. 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 6] 
                        RTCP with Unicast Feedback 
    
    
6.3 Receiver behaviour 
   Receivers listen on the RTP and RTCP channels for data. Each 
   receiver calculates its share of the receiver bandwidth based on the 
   standard rules, i.e., 75% of the RTCP bandwidth is divided equally 
   between all unique SSRCs in the session. See Section 9 for further 
   information on the calculation of the bandwidth allowance. When a 
   receiver is eligible to transmit, it sends a unicast Receiver Report 
   packet to the RTCP port of the distribution source. 
    
7. Sender feedback summary model 
   In the sender feedback summary mode, the sender is required to 
   summarise the information received from all the Receiver Reports 
   generated by the receivers and place the information into summary 
   reports. The sender feedback summary model introduces two new 
   packets. The Receiver Summary Information packet (RSI) which must be 
   sent by a source if the summarised feedback mechanism is selected 
   and the optional General Summary Report packet (GSR) that may be 
   appended to the RSI packet to provide more detailed information on 
   the overall session characteristics reported by all receivers. 
 
   The sender must send at least one Receiver Summary Information 
   packet for each reporting interval. The sender can additionally 
   stack General Summary Reports(GSRs) after the RSI packet. Each GSR 
   packet corresponds to the initial RSI packet and acts as an 
   enhancement to the basic summary information required by the 
   receivers to calculate their reporting time interval. For this 
   reason, GSR packets are not required but recommended. RSI and GSR 
   packets are sent in addition to the standard Sender Reports and SDES 
   packets outlined in [1]. 
    
7.1 Packet Formats 
    
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 7] 
                        RTCP with Unicast Feedback 
    
7.1.1 RSI: Receiver Summary Information RTCP Packet 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
|V=2|P|    SC   |      PT       |             length            |  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
|                         SSRC of Sender                        | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
|                           Timestamp                           | 
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+  
|                           group size                          |  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
|      AFL      |                    HCNL                       |  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
|                   Highest interarrival jitter                 |  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
|                    Receiver RTCP Bandwidth                    |  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
|                       collision SSRC #1                       |  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
|                             . . .                             |  
    
    
   The RSI packet consists of a main report block modeled along the 
   same lines as a Receiver Report with optional GSR blocks appended. 
   The first eight bytes of header extension follow the standard RTP 
   header outline. This ensures backwards compatibility with older 
   versions that may not understand the RSI packet format but can read 
   the length field indicating the end of the report block. The 
   following fields are included: 
        
   The fields "V", "P", and "length" have the same meaning as per [1].    
    
   SC: 5 bits 
      The number of collision SSRC entries towards the end of the 
      report block. A value of 0 is allowed, indicating that no 
      collisions are reported.  
          
   SSRC: 32 bits 
      The synchronisation source identifier for the originator of the 
      summary report packet. 
    
   timestamp: 32 bits 
      The time the packet was sent. This is an unsigned integer value 
      displayed in NTP timestamp units to enable detection of duplicate 
      packets, reordering and to provide a chronological profile of the 
      feedback reports. 
          
   group size: 32 bits 
      This field provides the sender's view of the number of receivers 
      in a session. This should include the sender itself and any other 
      senders potentially connected to the session e.g. via a 
      mixer/translator gateway. The group size is calculated according 
      to the rules outlined in [1]. 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 8] 
                        RTCP with Unicast Feedback 
    
          
   average fraction lost (AFL): 8 bits  
      The average fraction lost indicated by Receiver Reports forwarded 
      to this source, expressed as a fixed point number with the binary 
      point at the left edge of the field. 
     
   highest cumulative number of packets lost (HCNL): 24 bits 
      Highest 'cumulative number of packets lost' value out of all RTCP 
      RR packets since the last RSI from any of the receivers. 
    
   highest interarrival jitter: 32 bits 
      Highest 'interarrival jitter' value out of all RTCP RR packets 
      since the last RSI from any of the receivers.  
       
   receiver bandwidth: 32 bits 
      indicates the maximum bandwidth allocated to any single receiver 
      for sending RTCP data relating to the session. This is a fraction 
      value indicating a percentage of the session bandwidth, expressed 
      as a fixed point number with the binary point at the left edge of 
      the field. 
       
   collision SSRC: n x 32 bits 
      the final fields in the packet are used to identify any SSRCs 
      that are duplicated within the group. Usually this is handled by 
      the hosts upon detection of the same SSRC, however since 
      receivers no longer have a global view of the session, the 
      collision algorithm is handled by the source. SSRCs that collide 
      are listed in the packet and it is the responsibility of the 
      receiver(s) to detect the collision and select another SSRC. 
 
7.1.2 GSR: General Summary Report RTCP Packet Header 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|V=2|P|    BC   |      PT       |            Length             |header 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                         SSRC of Sender                        | 
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
|                             ...                               |report 
|                             ...                               |blocks 
 
 
   The GSR packet is a three-level structure composed of a header and 
   zero or more report blocks, each of which describes a range of 
   distribution values. The report blocks are a variable length, with a 
   fixed header and are described in subsequent sections.   
    
   The fields "V", "P", and "length" have the same meaning as per [1].    
    
   block count (BC): 5 bits 
      The number of report blocks contained in this packet 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 9] 
                        RTCP with Unicast Feedback 
    
    
   SSRC of Sender: 32 bits 
      The SSRC of the distribution source 
    
    
7.1.3 GSR Report block 
    
    
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
|       DT      |          NDB          |   MF  |     Length    | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                   Minimum Distribution Value                  | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       
|                   Maximum Distribution Value                  | 
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
|                      Distribution Buckets                     | 
|                             ...                               | 
|                             ...                               | 
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
    
    
    
   distribution type (DT): 8 bits 
      A numeric identifier to indicate the significance of the 
      distribution values. The items currently defined are described in 
      the next sections. Additional items may be defined in a separate 
      profile by registering the type numbers with IANA, see Section 
      12. 
    
   number of distribution buckets (NDB): 12 bits 
      The number of distribution Buckets within the data. The size of 
      the bucket can be calculated using the formula, number of bits 
      equals (length * 4 * 8)/NDB. Providing 12 bits enables bucket 
      sizes as small as 2 bits for a full length packet. The bucket 
      size in bits must always be divisable by 2 to ensure byte 
      alignment. A bucket size of 2 bits is fairly restrictive, 
      however, and it is expected that larger bucket sizes will be more 
      practical for most distributions. 
          
   multiplicative factor (MF): 4 bits 
      Indicates the multiplicative factor to be applied to each 
      distribution Bucket value. Possible values are 1 - 15. 
    
   length: 8 bits 
      The length of the whole GSR data packet in 4 byte units. The full 
      length of the packet in bytes is calculated by multiplying the 
      length value by 4. This tells the receiver the full length of the 
      packet and enables the receiver to identify the bucket size. The 
      maximum data portion of the packet therefore may be 1008 bytes 
      which would provide up to 4032 data buckets of length 2 bits, or 
      2016 data buckets of length 4 bits etcà. 
    
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 10] 
                        RTCP with Unicast Feedback 
    
   minimum distribution value: 32 bits 
      The Minimum distribution value, in combination with the Maximum 
      Distribution value, indicates the range covered by the Data 
      Bucket values. 
    
   maximum distribution value: 32 bits 
      The Maximum distribution value, in combination with the Minimum 
      Distribution value, indicates the range covered by the Data 
      Bucket values. 
    
   distribution buckets: each bucket is((length * 4) û 12)*8/NDB bits 
      The size and number of buckets depends upon the value of NDB and 
      the length of the packet. In order to calculate the size of the 
      bucket, the formula ((length * 4) û 12)*8/NDB should be used. 
      This indicates the division of the data space and the size of 
      each data point in bits. Each value must be multiplied by the 
      multiplicative factor. 
    
   Interpretation of the minimum, maximum and distribution values in 
   the report block are profile-specific and are addressed 
   individually. The size of the report block is variable, as indicated 
   by the packet length field. 
    
    
7.1.4 GSR Loss report block 
   GSR loss report blocks indicate the distribution of losses as 
   reported by the receivers to the distribution source. Values are 
   expressed as a fixed point number with the binary point at the left 
   edge of the field. The distribution type is 1. 
    
   Valid results for the Minimum Distribution Value field are 0 - 99, 
   otherwise interpreted as 0 - 0.99. Similarly, Valid results for the 
   maximum distribution value field are 1 - 100, otherwise interpreted 
   as 0.1 - 1. The Minimum Distribution Value must always be less than 
   the maximum. 
    
   For examples on processing GSR loss report blocks, see the Appendix. 
    
    
7.1.5 GSR Jitter report block  
   GSR jitter report blocks indicate the distribution of the estimated 
   statistical variance of the RTP data packet interarrival time 
   reported by the receivers to the distribution source. See [1] for 
   details on how the values are calculated and the relevance of the 
   jitter results. Jitter values are measured in timestamp units and 
   expressed as unsigned integers. The Minimum Distribution Value must 
   always be less than the maximum. The distribution type is 2. 
    
7.1.6 GSR Round Trip Time report block 
   GSR round trip time reports indicate the distribution of round trip 
   times from the distribution source to the receivers. The 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 11] 
                        RTCP with Unicast Feedback 
    
   distribution source is the only member of the group capable of 
   calculating the round trip time to any other members since it is the 
   only sender in the group. The sender has the option of distributing 
   these round trip time estimations to the whole group, uses of which 
   are described in Section 7.4. Round trip times are measured in 
   timestamp units and expressed as unsigned integers. The 
   multiplicative factor can be used to reduce the number of bits 
   required to represent the values. The Minimum Distribution Value 
   must always be less than the maximum. The distribution type is 3. 
    
7.1.7 SSRC Distribution report block 
   SSRC Distributions are an optional feature that can be provided by 
   the distribution source to indicate the allocation of SSRCs across 
   the group. SSRCs are expressed as unsigned integers. The 
   multiplicative factor can be used to reduce the number of bits 
   required to represent the values. The Minimum Distribution Value 
   must always be less than the maximum. The distribution type is 4. 
    
7.2 Distribution Source behaviour 
   The length field of the RSI packet must be calculated over the 
   length of the whole RSI packet, using the method defined in [1]. The 
   group size must be included in the RSI packet. The source should 
   also calculate the Receiver RTCP bandwidth field. Typically this 
   value will be calculated as outlined in [1] using the group size and 
   session bandwidth as variables. This field however does provide the 
   source with the capability to control the amount of feedback from 
   the receivers and can be increased or decreased based on the 
   requirements of the source. Regardless of the value selected by the 
   source for the RTCP bandwidth field, the source must continue to 
   forward Sender reports and RSI packets at the rate allowed by its 
   bandwidth allocation. See Section 9 for further details. 
    
   In order to identify SSRC collisions, the source is responsible for 
   maintaining a record of each SSRC and the corresponding CNAME within 
   at least one reporting interval in order to differentiate between 
   clients. It is recommended that an updated list of more than one 
   interval be maintained to increase accuracy. This mechanism should 
   prevent the possibility of collisions since the combination of SSRC 
   and CNAME should be unique if the CNAME is generated correctly. In 
   the event that collisions are not detected, the effect will be an 
   inaccurate impression of the group size on the part of the source. 
   Since the statistical probability that collisions will both occur 
   and be undetectable is very low, the clients would have to randomly 
   select the same SSRC and have the same username + IP address (e.g. 
   using private address space behind a NAT router), this should not be 
   a significant concern.  
    
   For the GSR packet, the source must decide which are the most 
   significant feedback values to convey. The packet format provides 
   flexibility in the amount of detail conveyed by the data points. 
   There is a trade-off between the granularity of the data and the 
   accuracy based on the factorisation values, the number of buckets 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 12] 
                        RTCP with Unicast Feedback 
    
   and the min and max values. In order to focus on a particular region 
   of the distribution, the source can adjust the minimum and maximum 
   values and either increase the number of buckets and possibly the 
   factorisation, or decrease the number of buckets and provide more 
   accurate values. See Appendix B for detailed examples on how to 
   convey information in RTCP Receiver Reports as GSR information. 
         
   The results should correspond as near as possible to the values 
   received during the interval since the last report. The source may 
   stack as many report blocks as required in order to convey different 
   distributions. If the distribution size exceeds the largest packet 
   length (1008 bytes data portion), more packets may be stacked with 
   additional information up to the MTU of the connection. 
    
    
7.3 Receiver behaviour 
   The receiver must process RSI packets and adapt session parameters 
   such as the RTCP bandwidth based on the information received. The 
   receiver no longer has a global view of the session, and will 
   therefore be unable to receive information from individual receivers 
   aside from itself. However, the information portrayed by the source 
   can be extremely detailed, providing the receiver with an accurate 
   view of the session quality overall, without the processing overhead 
   associated with listening to and analysing all the Receiver Reports. 
       
   The SSRC collision list must be checked against the SSRC selected by 
   the receiver to ensure there are no collisions. The group size value 
   provides the receiver with the data necessary to calculate it's 
   share of the RTCP bandwidth. This share of the bandwidth may be 
   overridden by the 'Receiver RTCP Bandwidth' field. This field 
   provides the source with the capability to control the amount of 
   feedback from the receivers.  
          
   The receiver can handle the GSR data as desired. This data is most 
   useful in providing the receiver with a more global view of the 
   conditions experienced by other receivers, and enables the client to 
   place itself within the distribution and establish the extent to 
   which it's reported conditions correspond to the group reports as a 
   whole. Appendix A provides further information and examples of data 
   processing at the receiver. 
         
   The receiver should assume that any report blocks in the same packet 
   correspond to the same data set received by the source during the 
   last reporting time interval. This applies to packets with multiple 
   blocks, where each block conveys a different range of values. 
 
    
7.4 Analyzing summarised reports 
   Providing a distribution function in a feedback message has a number 
   of uses for different types of applications. Although this section 
   enumerates potential uses for the distribution scheme, it is 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 13] 
                        RTCP with Unicast Feedback 
    
   anticipated that future applications might benefit from it in ways 
   not addressed in this document. Due to the flexible nature of the 
   GSR packet 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 combined make up a larger distribution tree. 
    
   A distribution function 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, which does 
   not have a global view, would be able to tune the degree of 
   redundancy built in to 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 receiver to make a more informed decision about whether it should 
   leave a group when it is 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.    
    
   - 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 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 14] 
                        RTCP with Unicast Feedback 
    
   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. 
 
 
8. Mixer/Translator issues 
   The original RTP specification allows for the use of mixers and 
   translators in an RTP session which help to connect heterogeneous 
   networks into one session. There are a number of issues, however, 
   which are raised by the unicast feedback model proposed in this 
   document. The term 'mixer' refers to devices that provide data 
   stream multiplexing where multiple sources are combined into one 
   stream. Conversely, a translator does not multiplex streams, but 
   simply acts as a bridge between two distribution mechanisms, e.g., a 
   unicast-to-multicast network translator. Since the issues raised by 
   this draft apply equally to either a mixer or translator, they are 
   referred to from this point onwards generically as a gateway.  
       
   A gateway between distribution networks in a session must ensure 
   that all members in the session receive all the relevant traffic to 
   enable the usual operation by the clients. A typical use may be to 
   connect an older implementation of an RTP client with an SSM 
   distribution network, where the client is not capable of unicasting 
   feedback to the source. In this instance the gateway must join the 
   session on behalf of the client and send and receive traffic from 
   the session to the client. Certain hybrid scenarios may have 
   different requirements. 
    
    
8.1 Use of a mixer-translator 
   The gateway must adhere to the SDP descriptor for the single source 
   session and use the feedback mechanism indicated. Receivers should 
   be aware that by introducing a gateway into the session, more than 
   one source may potentially be active in a session since the gateway 
   may be forwarding traffic from either multiple unicast sources or 
   from an ASM session to the SSM receivers. Receivers should still 
   forward unicast RTCP reports in the usual manner to the distribution 
   source, which in this case would be the gateway itself. It is 
   recommended that the simple packet reflection mechanism be used 
   under these circumstances since attempting to coordinate RSI + LJS 
   reporting between more than one source may be complicated unless the 
   gateway is capable of undertaking the summarisation itself. 
    
    
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 15] 
                        RTCP with Unicast Feedback 
    
8.2 Encryption and Authentication issues 
   Encryption and security issues are discussed in detail in Section 
   11. A gateway must be able to follow the same security policy as the 
   client in order to unicast forward RTCP data to the source, and it 
   therefore must be able to apply the same authentication and/or 
   encryption policy required for the session. Transparent bridging, 
   where the gateway is not acting as the distribution source, and 
   subsequent unicast feedback to the source is only allowed if the 
   gateway can conduct the same source authentication as required by 
   the receivers. 
    
    
9. Transmission interval calculation 
   The Control Traffic Bandwidth referred to in [1] is an arbitrary 
   amount which is intended to be supplied by a session management 
   application (e.g., [9]) or decided based upon the bandwidth of a 
   single sender in a session. A receiver must calculate the number of 
   other members in a session based upon either its own SSRC count 
   determined by the forwarded Receiver Reports, or from the RSI report 
   from a sender.  
    
   The RTCP transmission Interval calculation remains the same as in 
   the original RTP specification [1]. In the original specification, 
   the senders are allocated 1/4 of the control traffic bandwidth if 
   they number 25% or less than the group size. Otherwise the 
   allocation for senders is the percentage of senders to group size. 
   The remaining bandwidth is allocated to the receivers to be divided 
   evenly amongst the group. The source should calculate the 
   transmission interval for RSI + LJS packets out of its 1/4 of the 
   control traffic bandwidth with a minimum transmission interval of 5 
   seconds. 
    
    
10. SDP Extensions 
   The Session Description Protocol (SDP) is used as a means to 
   describe media sessions in terms of their transport addresses, 
   codecs, and other attributes. Providing RTCP feedback via unicast as 
   specified in this document constitutes another session parameter 
   needed in the session description. Similarly, parameters of SSM RTCP 
   feedback -- such as the mode of summarizing information at the 
   sender and the target unicast address to which to send feedback 
   information -- need to be provided.  This section defines the SDP 
   parameters that are needed by the proposed mechanisms in this draft 
   (and that also need to be registered with IANA). 
    
       
10.1 SSM RTCP Session Identification 
   A new session level attributes MUST be used to indicate the use of 
   unicast instead of multicast feedback: "rtcp:unicast". 
    
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 16] 
                        RTCP with Unicast Feedback 
    
   This attribute uses one additional parameter to specify the mode of 
   operation. 
    
   rtcp:unicast reflection -- MUST be used to indicate packet 
   reflection by the RTCP target (without further processing). 
    
   rtcp:unicast gsr        -- MUST be used to indicate the "General 
   Summary Report" mode of operation. 
                                
   rtcp:unicast rsi        -- MUST be used to indicate the "Receiver 
   Summary Information" mode of operation. 
    
    
10.2 SSM Source Specification 
   In addition, in an SSM RTCP session, the sender(s) need to be 
   indicated for both source-specific joins to the multicast group as 
   well as for addressing RTCP packets to. 
       
   This is done following the proposal for SDP source filters 
   documented in draft-ietf-mmusic-sdp-srcfilter-00.txt [15]. 
    
   From this specification, only the inclusion mode ("a=incl:") MUST be 
   used for SSM RTCP. 
    
   There SHOULD be exactly one "a=incl:" attribute listing the address 
   of the sender.  The RTCP port MUST be derived from the m= line of 
   the media description. 
    
   An optional alternative feedback address may be supplied using an 
   attribute such as a=rtcp:<port> IN IP4 192.168.1.1. 
    
    
11. Security Considerations 
    
11.1 Assumptions 
    
   RTP/RTCP is a protocol for carrying real-time multimedia traffic, 
   and therefore one of the main considerations for any security 
   solution must be to maintain as low an overhead as possible in order 
   to limit processing constraints. This includes the consideration of 
   overhead for different types of cryptographic operations on data, as 
   well as considerations for deploying or creating security 
   infrastructure for large groups. 
    
   The distribution of session parameters, typically using SDP type 
   information through SAP, email or the web is beyond the scope of 
   this document. It is recommended, however, that the method used 
   should employ adequate security measures to ensure the integrity and 
   authenticity of the information. For the purposes of this analysis, 
   it is assumed that the information has already been securely 
   distributed out-of-band. 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 17] 
                        RTCP with Unicast Feedback 
    
    
   It is also assumed that the multicast or group distribution 
   mechanism e.g. the SSM routing tree, is not immune to source IP 
   address spoofing or traffic snooping. All security weaknesses are 
   therefore addressed from a transport level perspective or above. 
    
11.2 Security threats 
    
   Attacks on this architecture may take a variety of forms, and in 
   order to identify the security weaknesses, it is important to 
   address these individually. 
    
   a) Denial of Service 
      A major area of concern would be a distributed denial of service 
      attack. Due to the nature of the communication architecture this 
      is a situation that could be generated a number of ways by using 
      the unicast feedback characteristic as a weakness. Since standard 
      multicast communication does not typically involve many to one 
      unicast forwarding of data, this poses new challenges for a 
      security solution. 
    
   b) Packet Forgery 
      One potential area of attack to guard against is packet forgery. 
      In particular, it is important to protect against the integrity 
      of certain influential packets since compromise of certain 
      control packets could directly affect the transmission 
      characteristics of the whole group, however for the purposes of 
      defining a security profile, every packet is considered equally 
      as important. In the case of a large group, the compromise of 
      RTCP traffic could have serious consequences.  
    
   c) Session Replay 
      An additional concern is the potential for session recording and 
      subsequent replay. The issue to deal with in particular in this 
      instance is that an attacker may not actually need to understand 
      the packet contents, but just simply have the ability to record 
      the data stream and at a later time replay it with a spoofed 
      source address. 
    
   d) Eavesdropping on a session 
      The consequences of eavesdropping by an attacker on a session may 
      not directly constitute a security weakness, however it might 
      benefit other types of attack, and should therefore be considered 
      as a potential threat to guard against.  
    
    
11.3 Security properties 
    
   Three types of security that may be applied to combat the issues 
   identified above seem relevant for these contexts. 
    
   a) Data integrity 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 18] 
                        RTCP with Unicast Feedback 
    
      This ensures that the data received from the network has not been 
      tampered with by any third party, either maliciously or through a 
      network error. This type of test ensures that the packet received 
      is guaranteed to be in exactly the same condition as that source 
      intended it to be. This does not guard against the authenticity 
      of the source that created the packet. 
    
   b) Data authenticity 
      In order to determine what entity is generating certain data, an 
      authenticity mechanism is required. This guarantees that the 
      creator of the data is known to the receiver and that the 
      receiver can trust the content of the data assuming the data 
      integrity has also been secured. 
    
   c) Data confidentiality 
      In order to restrict information access to authorized entities, 
      confidentiality may also be required. This ensures that only 
      authorized clients can understand the data that they receive. It 
      does not prevent eavesdroppers receiving the traffic and having 
      the capability to replay information in it's original form to 
      other clients with the capability to understand the information. 
    
   d) Replay protection 
      Ensures that given some pre-determined range of either time or 
      session values, a host can determine whether the data was 
      transmitted within the given window. 
     
 
11.4 Architectural Contexts 
    
   In order to understand the potential weaknesses to guard against, it 
   is necessary to divide the communication model into a number of 
   distinct contexts.  
    
   a) Source to Receiver communication 
      The first, and perhaps most influential context to protect, is 
      the ædownstreamÆ communication channel from the source to the 
      receivers. This is effectively the main controlling influence 
      over the behaviour of the group since it determines the bandwidth 
      allocation for each receiver and hence the rate at which the RTCP 
      traffic is directly unicast back to the source. All traffic that 
      is distributed over the downstream channel should be generated by 
      a single source. Both the RTP data stream and the RTCP control 
      data are sent over this channel. The RTCP data is indirectly 
      influenced by the information the source has received from the 
      whole group. 
       
      This context is vulnerable to all four attacks outlined in the 
      previous section. A denial of service attack from the source to 
      the receivers is possible, but less of a concern since the worst 
      case effect of sending large volumes of traffic over the 
      distribution channel has the potential to reach every receiver, 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 19] 
                        RTCP with Unicast Feedback 
    
      but only on a one-to-one basis, this is no different from the 
      current multicast model where an individual source may send large 
      volumes of traffic to a multicast group. 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 by mistake e.g. an IP 
      address typing error, could directly create a denial of service 
      attack on another host which must also be guarded against.  
       
      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. Other 
      consequences of packet forgery in this context may be the 
      compromise of data affecting the integrity of the data received 
      both in the RTP stream itself and the RTCP data in general. 
       
      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 very large 
      group. The consequences of this type of attack may be less 
      effective on their own, but in combination with other attacks 
      might be serious. 
       
      Eavesdropping on the session would provide an attacker with 
      information on the charateristics of the source to receiver 
      traffic such as the frequency of RTCP traffic and, if 
      unencrypted, might also provide valuable information on 
      characteristics such as group size and transmission 
      charateristics of the receivers back to the source in addition to 
      enabling an attacker to listen to the media streams. In this 
      context, the attacker might also have access to personal 
      information carried in the SDES packets such as email, phone and 
      full username information. 
    
   b) Receiver to source or gateway communication 
      The second context to address is the return traffic from the 
      group to the source or gateway which for the purposes of this 
      analysis may be considered in the same light as a distribution 
      source. This traffic should only be RTCP type data, and should 
      include receiver reports, SDES information and possibly 
      Application specific packets. The effects of compromise on a 
      single or subset of receivers is less likely to have as great an 
      impact as the first context, however much of the responsibility 
      for detecting compromise of the source data stream relies on the 
      receivers.  
       
      The effects of compromise of the first context with respect to 
      critical source RTCP control information would be witnessed most 
      seriously in the second context. A large group of receivers may 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 20] 
                        RTCP with Unicast Feedback 
    
      unwittingly generate a distributed DoS attack on the source in 
      the event that the intergrity of the source RTCP channel has been 
      compromised and the security breach is not detectable by the 
      individual receivers.  
       
      In the event that packet forgery may occur in this context, the 
      effect may be the introduction of false RTCP traffic and/or the 
      creation of fake SSRC identifiers. Such an attack might slow down 
      the overall control channel data rate, since an incorrect 
      perception of the group size may be created. This might affect 
      external issues such as group accounting and other as yet unknown 
      potential uses of the distribution functionality for controlling 
      group behaviour such as leader election based on feedback 
      criteria.  
       
      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. It is therefore equally as 
      important to protect against compromise of any receiver 
      contribution to the RTCP channel as it is to ensure authenticity 
      and freshness of the data source. 
    
      Eavesdropping in this context may potentially provide an attacker 
      with a great deal of 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 allowance. 
    
    
11.5 Requirements in each context 
    
   Some initial requirements to consider for each context in general 
   are that the overhead of ensuring the security of the session should 
   be kept as low as possible. This entails keeping the setup and 
   communication of shared or private keys to a minimum. The nature of 
   RTP/RTCP traffic is that sessions require real-time processing and 
   minimal overhead for communication. This means that processing 
   constraints imposed by techniques such as public/private key 
   encryption versus stream ciphers using shared keys are an important 
   consideration for defining this security profile. 
    
   Having identified the security weaknesses for each communication 
   context, security type requirements can be addressed for each. 
    
   a) The first context is concerned with denial of service attacks 
      through possible packet forgery. The forgery may take the form of 
      interception and modification of packets from the source, or 
      simply injecting false packets into the distribution channel. To 
      combat these attacks, data integrity and source authenticity are 
      required. The degree of confidentiality which may be deployed is 
      not a requirement in this context since the actual consequences 
      of eavesdropping do not affect the operation of the protocol, 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 21] 
                        RTCP with Unicast Feedback 
    
      however without confidentiality, access to personal and group 
      characteristics information would be unrestricted to an external 
      listener and it is therefore recommended. 
    
   b) The second context must defend against the same kinds of attacks. 
      Data integrity is required to ensure that interception and 
      modification of an individual receiverÆs RTCP traffic is not 
      accomplished. This is to protect against the false influence of 
      group control information and the possible serious compromise of 
      future services provided by the distribution functionality such 
      as leader election based on various parameters. In order to 
      ensure data integrity, receiver authenticity is therefore an 
      additional requirement in order to ensure the origin of the data 
      is secure. The same situation applies as in the first context 
      with respect to data confidentiality, and it is recommended that 
      precautions should be taken to protect the privacy of the data. 
 
 
11.6 Overview of existing security solutions 
    
   This section addresses some existing group security mechanisms and 
   identifies which aspects of the security requirements they might 
   provide. This security analysis is a work in progress, and these 
   options will be explored in more detail in subsequent versions of 
   the draft. 
    
   SRTP provides confidentiality of the RTP and RTCP packets as well as 
   protection against integrity compromise and replay attacks. It 
   provides authentication of the data stream, however it does not 
   provide authentication on a per-user basis. This means that a packet 
   can be authenticated as having originated from one of the session 
   members, but it does not indicate which member. All keys for an SRTP 
   session are derived from a single master key which it is assumed has 
   been distributed via some out-of-band secure method.  
    
   A more general group security profiles which should be considered 
   are the Group Domain of Interpretation which provides a solution for 
   multicast IPSec ESP security with group authentication.  
    
   GSAKMP is perhaps the most detailed solution which provides group 
   access control, key generation and facilities for rekeying the whole 
   group. 
    
   These options will be considered individually in later releases of 
   the draft. 
 
12. IANA Considerations 
   Based on the guidelines suggested in [10], this document proposes 2 
   new RTCP data payload types for consideration by IANA, and 4 new 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 22] 
                        RTCP with Unicast Feedback 
    
   sub-payload types for summary distribution types, defined in section 
   5. 
    
   Furthermore, four new SDP media-level attributes are defined in 
   Section 10. 
    
13. Outstanding Issues 
    
   6.2 Complication with detecting unicast versus multicast transmitted 
   data on the same port. 
    
   Add Backwards compatibility section 
    
   Include implications of recent changes to port/port+1 rules for 
   RTP/RTCP traffic. 
    
    
14. References 
   [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP - 
   A Transport Protocol for Real-time Applications," Internet     
   Draft, draft-ietf-avt-rtp-new-10.txt, Work in Progress, July 2001. 
    
   [2] Pusateri, T, "Distance Vector Multicast Routing Protocol", 
   draft-ietf-idmr-dvmrp-v3-10, August 2000 
    
   [3] Fenner, B, Handley, M, Holbrook, H, Kouvelas, I, "Protocol 
   Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification 
   (Revised)", draft-ietf-pim-sm-v2-new-02.txt, March 2001 
    
   [4] Farinacci, D, Kouvelas, I, Windisch, K, "State Refresh in PIM-
   DM" draft-ietf-pim-refresh-02.txt, November, 2000 
    
   [5] Thaler, D, Cain, B, "BGP Attributes for Multicast Tree 
   Construction", draft-ietf-idmr-bgp-mcast-attr-00.txt, February 1999 
    
   [6] Farinacci, D, Rekhter, Y, Meyer, D, Lothberg, P, Kilmer, H, 
   Hall, J, "Multicast Source Discovery Protocol (MSDP)", draft-ietf-
   msdp-spec-06.txt, July 2000 
    
   [7] Shepherd, G, Luczycki, E, Rockell, R, "Source-Specific Protocol 
   Independent Multicast in 232/8", draft-shepherd-ssm232-00.txt, March 
   2000. 
    
   [8] Holbrook, H, Cain, B, "Using IGMPv3 For Source-Specific  
   Multicast", draft-holbrook-idmr-igmpv3-ssm-00.txt, July 2000. 
       
   [9] Session Directory Rendez-vous (SDR), developed at University 
   College London by Mark Handley and the Multimedia Research Group.  
       
   [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 
   Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 
       
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 23] 
                        RTCP with Unicast Feedback 
    
   [11] Handley, M, Perkins, C, Whelan, E, "Session Announcement 
   Protocol", (SAP), RFC 2974, October 2000. 
       
   [12] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", 
   Netscape Communications Corp., Nov 18, 1996. 
       
   [13] Perrig, Canetti, Briscoe, Tygar, Song, "TESLA: Multicast Source 
   Authentication Transform", draft-irtf-smug-tesla-00.txt. 
       
   [14] E. Carrara, D. McGrew, M. Naslund, K. Norrman, D. Oran, "The 
   Secure Real Time Transport Protocol", draft-ietf-avt-srtp-01.txt. 
    
   [15] B. Quinn, "SDP Source-Filters", Internet Draft draft-ietf-
   mmusic-sdp-srcfilter-00.txt, Work in Progress, May 2000. 
    
    
15. Appendix 
A  GSR packet processing at the receiver 
 
A.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) 
   First data point = MnDV,first ydata 
   then 
   Foreach ydata => xdata += (MnDV + (xrange / NDB))     
A.2 Pseudo-code 
   Packet Variables -> factor,NDB,MnDVL,MaDV 
   Code variables -> xrange, ydata[NDB],x,y 
         
   xrange = MaDV - MnDV 
   x = MnDV; 
    
    
    
B GSR packet creation at the source 
   See Postscript version. 
    
C AUTHORS ADDRESSES 
   Julian Chesterfield 
   AT&T Labs - Research 
   75 Willow Road 
   Menlo Park, CA 94025 
   julian@research.att.com 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 24] 
                        RTCP with Unicast Feedback 
    
    
   Eve Schooler 
   AT&T Labs - Research 
   75 Willow Road 
   Menlo Park, CA 94025 
   schooler@research.att.com 
    
   Joerg Ott 
   Tellique Kommunikationstechnik GmbH 
   Berliner Str. 26 
   D-13507 Berlin 
   GERMANY 
   Phone: +49.30.43095-560  (sip:jo@tzi.org) 
   Fax:   +49.30.43095-579 
   Email: jo@tellique.com 
    
D FULL COPYRIGHT STATEMENT 
   Copyright (C) The Internet Society (2000). All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works.  However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet languages other than English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
     
   Chesterfield    Internet Draft - Expires December 2002     [Page 25]