Internet Engineering Task Force Audio/Video Transport Working Group Internet Draft Timur Friedman, UMass Amherst 10 March 2000 Ramon Caceres, AT&T Labs Expires 10 September 2000 Kevin Almeroth, UCSB Kamil Sarac, UCSB RTCP Reporting Extensions draft-friedman-avt-rtcp-report-extns-00.txt 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. Internet Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document defines a format for extensions to the RTCP SR (sender report) and RR (receiver report) packets that are defined in the RTP specification. Within their "reception report blocks", SR and RR packets are limited to reporting six specified statistics on any given data source. This document describes how other information can be reported in "extended report blocks" that are stacked at the end of an SR or RR packet. Some specific block formats are provided here. For other formats that may be defined as the need arises, this document specifies a simple framework that they must adhere to. Friedman, Caceres, Almeroth, and Sarac [Page 1]
draft-friedman-avt-rtcp-report-extns-00.txt 10 March 2000 1. Introduction This document defines extended report blocks for RTCP, the control portion of RTP [5]. These blocks convey information over and above that which is already contained in the reception report blocks of RTCP's SR or RR packets. For example, while a reception report block has an average loss rate field, an application might opt to use an extended report block that details exactly which packets were received and which were lost. The framework for these blocks is minimal: just a type field and a length field are required. Purpose being to maintain flexibility and to keep overhead low. Some specific block formats are provided here, and others may be defined as the need arises. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [2] and indicate requirement levels for compliant RTP implementations. 2. Extended Report Block Framework The RTP specification provides for profile-specific extensions to RTCP's SR and RR packets. This document defines a basic framework for those extensions, and so constitutes a reporting profile for RTP. Extended report blocks MUST be stacked, one after the other, at the end of an SR or RR packet, in the portion reserved for profile- specific extensions. An individual block's length MUST be a multiple of 4 octets. The SR or RR header's length field MUST describe the total length of the packet, including these extended report blocks. Each block has block type and length fields that facilitate parsing. A receiving application can demultiplex the blocks based upon their type, and can use the length information to locate each successive block, even in the presence of block types it does not recognize. No other fields are required. An extended report block has the following format: Friedman, Caceres, Almeroth, and Sarac [Page 2]
draft-friedman-avt-rtcp-report-extns-00.txt 10 March 2000 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT | type-specific | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : type-specific data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits Identifies the specific block format. type-specific: 8 bits The use of these bits is defined by the particular block type. length: 16 bits The length of this report block in 32-bit words minus one, including the header. type-specific data: variable length This MUST be a multiple of 32 bits long. It MAY be zero bits long. 3. Specific Extended Report Blocks This section defines five extended report blocks: an experimental block type and block types for losses, duplicates, timestamps, and detailed statistics. Other block types MAY be defined in the future. Any such definition MUST include block type numbers assigned by the Internet Assigned Numbers Authority [4]. 3.1 Experimental Block This type MUST be used for extended report block types that have not been standardized. In addition to the standard type and length fields, it includes a 32 bit name field that serves to distinguish one experimental block type from another. It is otherwise freely open to definition. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=0 | app-specific | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name (ASCII) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : application-specific data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Friedman, Caceres, Almeroth, and Sarac [Page 3]
draft-friedman-avt-rtcp-report-extns-00.txt 10 March 2000 block type (BT): 8 bits Block type 0 identifies this as an experimental block. app-specific: 8 bits The use of these bits is defined by the application that uses this block. length: 16 bits The length of this report block in 32-bit words minus one, including the header. name: 4 octets A name chosen by the person definining the experimental block to be unique with respect to other experimental blocks the application might receive. application-specific data: variable length. This MUST be a multiple of 32 bits long. It MAY be zero bits long. 3.2 Loss RLE Block With this block type, a boolean trace of lost and received packets can be conveyed in compressed form using run length encoding. Caution SHOULD be used in sending such blocks because, even with compression, they can easily consume bandwidth out of proportion with normal RTCP packets. Each block reports on a single source, identified by its SSRC. The receiver that is supplying the report is identified in the header of the RTCP packet. The beginning and ending sequence numbers for the trace are specified in the block, the ending sequence number being the last sequence number in the trace plus one. The last sequence number in the trace MAY or may not be the sequence number reported on in an SR or RR report block, depending on the needs of the application. The encoding itself consists of a series of 16 bit chunks. Each chunk either specifies a run length or a bit vector, or, if the trace otherwise encodes into an odd number of chunks, MUST be a terminating null chunk used to round out the block to a 32 bit word boundary. The mapping from a sequence of lost and received packets into a sequence of chunks is not unique and is left to the application. A run length chunk can describe runs of between 1 and 16,383 packet losses or receipts whereas a bit vector chunk can describe a sequence of 15 packet losses and receipts. It is RECOMMENDED that the description of run lengths of 14 or shorter be subsumed into bit Friedman, Caceres, Almeroth, and Sarac [Page 4]
draft-friedman-avt-rtcp-report-extns-00.txt 10 March 2000 vector chunks, for purposes of brevity. A bit vector chunk MAY purport to contain information on packets at or beyond the ending sequence number. Any such purported information MUST be ignored. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=1 | unused | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits Contains the constant 1 to identify this as a run-length encoding block with 16 bit chunks. unused: 8 bits This field is not used. length: 16 bits The length of this report block in 32-bit words minus one, including the header. begin_seq: 32 bits The first sequence number that this block reports on. end_seq: 32 bits The last sequence number that this block reports on plus one. chunk i: 16 bits There are three chunk types: run length, bit vector, and terminating null. If the chunk is all zeroes then it is a terminating null. Otherwise, the leftmost bit of the chunk determines its type: 0 for run length and 1 for bit vector. Friedman, Caceres, Almeroth, and Sarac [Page 5]
draft-friedman-avt-rtcp-report-extns-00.txt 10 March 2000 3.2.1 Run-Length Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R| run length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A zero identifies this as a runlength chunk. run type (R): 1 bit Zero indicates a run of losses. One indicates a run of received packets. run length: 14 bits A value between 1 and 16,383. I.e. MUST not be zero (zeroes in both the run type and run length fields would make the chunk a terminating null chunk). Run lengths of 15 or less MAY be described with a run length chunk despite the fact that they could also be described as part of a bit vector chunk. 3.2.2 Bit Vector Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| bit vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A one identifies this as a bit vector chunk. bit vector: 15 bits In the bit vector, as in the run length chunk, a zero indicates a loss and a one indicates a received packet. 3.2.3 Terminating Null Chunk This chunk is all zeroes. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Friedman, Caceres, Almeroth, and Sarac [Page 6]
draft-friedman-avt-rtcp-report-extns-00.txt 10 March 2000 3.3 Duplicate RLE Block This block is identical in format to the Loss RLE Block type but carries information about individual or runs of duplicate packets. A zero indicates the presence of duplicate packets for a given sequence number, whereas a one indicates that no duplicates were received. Note that a packet loss is encoded as a one in this case. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=2 | unused | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits Contains the constant 2 to identify this as a run-length encoding block with 16 bit chunks for duplicates. unused: 8 bits This field is not used. length: 16 bits The length of this report block in 32-bit words minus one, including the header. begin_seq: 32 bits The first sequence number that this block reports on. end_seq: 32 bits The last sequence number that this block reports on plus one. chunk i: 16 bits There are three chunk types: run length, bit vector, and terminating null. All zeroes indicates a terminating null. Otherwise, the Friedman, Caceres, Almeroth, and Sarac [Page 7]
draft-friedman-avt-rtcp-report-extns-00.txt 10 March 2000 leftmost bit of the chunk determines its type: 0 for run length and 1 for bit vector. See the descriptions of these block types in the section on the Loss RLE Block, above, for details. 3.4 Timestamp Report Block This block carries RTCP-style timestamps for each packet in the range of packet sequence numbers. A similar caution, but more emphatic, is made for timestamp report blocks as was made for Loss RLE Block packets. For each packet in the sequence number range, a 32 bit value MUST be recorded and sent. This could easily consume significant bandwidth. Care SHOULD be taken in the size of the sequence space over which to monitor timestamps. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3 | unused | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp (pkt n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits Contains the constant 3 to identify this as a block of packet timestamps. unused: 8 bits This field is not used. length: 16 bits The length of this report block in 32-bit words minus one, including the header. begin_seq: 32 bits The first sequence number that this block reports on. end_seq: 32 bits The last sequence number that this block reports on plus one. Friedman, Caceres, Almeroth, and Sarac [Page 8]
draft-friedman-avt-rtcp-report-extns-00.txt 10 March 2000 RTP timestamp: 32 bits Corresponds to the same units as the RTP timestamp in RTP data packets. Measured upon packet arrival. Can be used to measure partial path characteristics and to model distributions for packet jitter. 3.5 Statistics Summary Block This block reports detailed statistics above and beyond the information carried in the standard RTCP packet format. Information is recorded about lost packets, duplicate packets, jitter measurements, and TTL values. The packet contents are dependent upon a bit vector carried in the first part of the header. Not all values need to be carried in each packet. Header fields for values not carried are not included in the packet. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=4 |L|D|J|T| unused| length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lost_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dup_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | max_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | avg_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dev_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_ttl | max_ttl | avg_ttl | dev_ttl | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits Contains the constant 4 to identify this as a statistics summary report block. Friedman, Caceres, Almeroth, and Sarac [Page 9]
draft-friedman-avt-rtcp-report-extns-00.txt 10 March 2000 content bits (L,D,J,T): 4 bits Bit set to 1 if packet contains (L)oss, (D)uplicate, (J)itter, and/or (T)TL report. unused: 4 bits This field is not used. length: 16 bits The length of this report block in 32-bit words minus one, including the header. begin_seq: 32 bits The first sequence number that this block reports on. end_seq: 32 bits The last sequence number that this block reports on plus one. lost_packets: 32 bits Number of lost packets in the above sequence number interval. dup_packets: 32 bits Number of duplicate packets in the above sequence number interval. min_jitter: 32 bits The minimum relative transit time between two packets in the above sequence number interval. All jitter values are measured as the difference between a packet's RTP timestamp and the reporter's clock at the time of arrival, measured in the same units. max_jitter: 32 bits The maximum relative transit time between two packets in the above sequence number interval. avg_jitter: 32 bits The average relative transit time between each two packet series in the above sequence number interval. dev_jitter: 32 bits The standard deviation of the relative transit time between each two packet series in the above sequence number interval. min_ttl: 8 bits The minimum TTL value of data packets in sequence number range. max_ttl: 8 bits The maximum TTL value of data packets in sequence number range. Friedman, Caceres, Almeroth, and Sarac [Page 10]
draft-friedman-avt-rtcp-report-extns-00.txt 10 March 2000 avg_ttl: 8 bits The average TTL value of data packets in sequence number range. dev_ttl: 8 bits The standard deviation of TTL values of data packets in sequence number range. 4. Acknowledgements We thank the following people: Colin Perkins, Steve Casner, and Henning Schulzrinne for their considered guidance; and Sue Moon for helping foster our collaboration. 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11 [3]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. References [1] S. Bradner, "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, IETF, October 1996. [2] S. Bradner, "Key words for use in RFCs to indicate requirement levels," BCP 14, RFC 2119, IETF, March 1997. [3] R. Hovey and S. Bradner, "The Organizations Involved in the IETF Standards Process," BCP 11, RFC 2028, IETF, October 1996. [4] J. Reynolds and J. Postel, "Assigned Numbers," STD 2, RFC 1700, IETF, October 1994. Friedman, Caceres, Almeroth, and Sarac [Page 11]
draft-friedman-avt-rtcp-report-extns-00.txt 10 March 2000 [5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A transport protocol for real-time applications," RFC 1889, IETF, February 1996. 7. Full Copyright Statement Copyright (C) The Internet Society (1999). 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 Standards process must be followed, or as required to translate it into 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. Friedman, Caceres, Almeroth, and Sarac [Page 12]
draft-friedman-avt-rtcp-report-extns-00.txt 10 March 2000 8. Authors' Addresses Timur Friedman <friedman@cs.umass.edu> Computer Science Department UMass Amherst Amherst, MA 01003, USA Ramon Caceres <ramon@research.att.com> AT&T Labs-Research 180 Park Avenue, Building 103 Florham Park, NJ 07932, USA Kevin Almeroth <almeroth@cs.ucsb.edu> Department of Computer Science University of California Santa Barbara, CA 93106, USA Kamil Sarac <ksarac@cs.uscb.edu> Department of Computer Science University of California Santa Barbara, CA 93106, USA Friedman, Caceres, Almeroth, and Sarac [Page 13]