Internet Engineering Task Force AVT WG Internet Draft Julian Chesterfield draft-chesterfield-avt-rtcpssm-00.txt AT&T Internet Research February 23, 2001 Expires: August 23, 2001 RTCP Extension for Source Specific Multicast Sessions 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 to enable the continued operation of RTP/RTCP in Source Specific Multicast (SSM) sessions where the traditional model of Internet Standard Multicast (ISM) group communication does not apply. This specification extends RFC 1889, section 6 which defines the RTP session group control channel. It modifies this functionality to enable continued operation of RTCP in a Source Specific Multicast Session where there is no bi-directional communication between all hosts. 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 [Page 1] Internet Draft RTCP for SSM February, 2001 2. Introduction 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 communication 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 calculation from other hosts. An additional advantage of providing a control channel for a session is that a third-party session monitor can listen to the traffic and establish network conditions and diagnose faults based on receiver locations. RTP was designed for the traditional mode of Internet Standard Multicast (ISM) Group communication which encompasses a network which supports both one to many and many to many communication 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 Distance Vector Multicast Routing Protocol (DVMRP) [2] or Protocol Independent Multicast (PIM) [3][4] Sparse/Dense Mode in combination with an Inter-domain routing protocol such as Border Gateway Multicast Protocol (BGMP) [5] with Multicast Source Discovery (MSDP) [6]. Such routing protocols enable a host to join a single Multicast group address and send to or receive traffic from all members in the group with no prior knowledge of membership. In order to enable such a service in the network, however there is a great deal of complexity involved at the routing level. 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 network is no longer required to distribute information regarding active sources to enable the flow of traffic to all hosts. There is instead a focal point for the group source, and a join message is passed by the receivers towards the host, notifying routers along the way of the status of multicast group membership. 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 SSM (Source, Group) or unicast join to the host. The solution proposed in this draft defines a new method for distributing control information amongst all members in an SSM session in the abscence of recievers being able to communicate with each other. The RTP data stream protocol itself is unaffected. SSM sessions are defined as being in the group address range 232.0.0.0 through 232.255.255.255. Therefore there should be no confusion in differentiating an SSM session from an ISM or unicast session. The following discussion applies exclusively to sessions in the SSM address range. Chesterfield [Page 2] Internet Draft RTCP for SSM February, 2001 This draft proposes two methods for enabling receiver feedback to all members in a session. Each involves the unicasting of RTCP packets to the source, whose job it is to distribute the information to the members of the group. The source is the only member in a group which can communicate with all the other members, and therefore much of the responsibility for maintaining the operation of RTCP is on the source. The first method is a basic mechanism whereby all receiver reports are unicast to the source and subsequently forwarded to all members. The advantage of this method is that apart from modifiying the destination address for feedback reports, a receiver implementation does not have to change very much in order for the protocol to operate. A second method is defined in section 5 where the source groups multiple receiver reports, removing the redundant infomation, and creates a single SR summary packet to send out to the group. This helps to conserve network bandwidth by reducing the amount of data in the control packet. 3. Packet types and host behaviour As in the original specification, the main rtp data stream is carried on an even port number. For SSM, the address will be an (S,G) combination. The RTCP control channel is therefore carried on the same address but on the next higher (odd) port number. The receivers must additionally open a unicast socket to the source using the source IP address, which is known to the receiver in advance, and RTCP channel port (odd). The receiver will not receive any unicast data on this address/port pair. Any communication from the source will be via the SSM control channel. The RTCP packet types defined in RFC 1889 are: abbrev. name value SR sender report 200 RR receiver report 201 SDES source description 202 BYE goodbye 203 APP application-defined 204 The modifications to these are described in the following sections. 4. Simple feedback model This model remains mostly similar to the original specification. The differences for each packet type are discussed below:- Chesterfield [Page 3] Internet Draft RTCP for SSM February, 2001 SR: Sender report, for transmission and reception statistics from the source. The core functionality remains unchanged, however since there is only one source in a session, the stacking of additional RRs in the packet in the form previously described would be unused. Therefore a small modification is proposed:- Since any packet received on the multicast control channel can be assumed to have come from the source, identified in the sixth field (bytes 5 - 8) of the SR packet header, each subsequent SSRC field of each report block will therefore be changed to the SSRC value of the receiver which sent the report and will contain the receiver report information from that SSRC. Diagram 3.1 is a modified version of the original SR packet specification in section 6.3.1 of rfc 1889. 3.1 SR: Sender report RTCP packet for SSM session 0 1 2 3 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| RC | PT=SR=200 | length | header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | NTP timestamp, most significant word | sender +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first receiver) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | fraction lost | cumulative number of packets lost | 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second receiver) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block : ... : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chesterfield [Page 4] Internet Draft RTCP for SSM February, 2001 RR: Receiver reports are for reception statistics from participants that are not active senders, therefore these packets will only be generated by the receivers. Since there is only one source in the session, these packets will contain at most 1 RR. SDES: Source description packet. This packet type is only issued by an active source and therefore will only be sent out by the sender. BYE: Indicates end of participation, the same mechanism should be used as in an ISM session. APP: Application specific functions, this packet type remains unchanged and should be specified on an individual application basis. The default operation of the sender, however is to forward any APP packets in their original format. In summary:- 1. RTCP RR packets are unicast to the source on the same port as the RTCP session channel. 2. The Sender Report packet format is modified as indicated in section 4.1. The reasoning behind this modification is that the sender has no other sources to report on, and therefore the packet format is being adjusted to enable forwarding of RTCP data. 3. Receiver report packets only contain 1 RR 5. Sender feedback summary model Since there is only one source, the simple feedback model, while maintaining the correct operation of RTCP, results in a substantial amount of redundancy of data. Therefore the Sender Feedback summary model is proposed to conserve the unnecessary use of network bandwidth. A new packet type is proposed called a Sender Summary Report or SSR which will consolidate the Receiver Reports by removing the timestamps which are only effective for the Source itself in calculating a Round Trip Time estimate to the receivers. The SSR packet is assigned the Payload value 205. The new SSR packet format therefore follows the SR format with minor changes:- Chesterfield [Page 5] Internet Draft RTCP for SSM February, 2001 0 1 2 3 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| RC | PT=SSR=205 | length | header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | NTP timestamp, most significant word | sender +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first receiver) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | fraction lost | cumulative number of packets lost | 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second receiver) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block : ... : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For each Report block, there is an 8 byte saving, e.g. in a session with 10 receivers, this would enable a saving of 80 bytes per sender report. 6. Transmission interval calculation In both feedback models the RTCP transmission Interval calculation is the same. In the original specification, Senders are allocated 1/4 of the control traffic bandwidth. The Control Traffic Bandwidth is an abitrary amount which is intended to be supplied by a session management application or decided based upon the bandwidth of a single sender in a session. Although the control channel is only effectively used by one member of the session, the aim of bandwidth Chesterfield [Page 6] Internet Draft RTCP for SSM February, 2001 allocation is to control the overall network usage, this includes the unicast Receiver reports which must be taken into account by the receivers even though they do not see them. An additional constraint for the sender is that the bandwidth allowance for the sender must be at least as great as the combined allowance for all the remaining session members since it is replicating all the data which they unicast. It is therefore recommended that in the case of SSR packet distribution, of the overall 5% allocation of the "session bandwidth" , 1/2 of this is allocated to the source for distributing SSR packets. It is anticipated that the additional saving in the SSR packet will provide adequate bandwidth for the sender's overhead of distributing SDES packets. The remaining 2.5% should be divided amongst the receivers. In the case of standard feedback, it is recommended that this allowance for the source be slightly higher, around 3% to account for the additional data overhead. A receiver still calculates the number of other members in a session based upon the SSRC count determined by the SR or SSR packets from the source. 7. Security Considerations There are no additional security considerations introduced by this scheme of which the author is aware at this time. The issue of source feedback implosion should not occur in the event that receivers prcatice the standard RTP/RTCP guidelines for starting sessions and for implementing scaling algorithms based on the number of hosts. An additional issue which should be addressed beyond the scope of this document is the potential for host anonymity which is facilitated by Source Specific Multicast and adds additional security measures into group communication. By explicitly controlling receiver feedback, a source could solicit feedback from the receivers in a scalable way without the need to inform all members in a session of the group membership. 8. References [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A transport protocol for real-time applications," RFC 1889, January 1996. [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-01.txt, November 2000 [4] Farinacci, D, Kouvelas, I, Windisch, K, "State Refresh in PIM-DM" draft-ietf-pim-refresh-02.txt, November, 2000 [5] Thaler, D, Estrin, D, Meyer, D, "Border Gateway Multicast Protocol (BGMP): Protocol Specification", draft-ietf-bgmp-spec-02.txt November, 2000 [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. AUTHORS' ADDRESS Julian Chesterfield AT&T Labs - Research 75 Willow Road Menlo Park, CA 94025 julian@research.att.com