Audio/Video Transport Working                                    G. Hunt
Group                                                                 BT
Internet-Draft                                                  A. Clark
Intended status: Standards Track                                Telchemy
Expires: April 28, August 29, 2009                                 October                               February 25, 2008 2009

             RTCP XR Report Block for Measurement Identity

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 28, August 29, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   This document defines an RTCP XR Report Block carrying parameters
   which identify a measurement, to which one or more other RTCP XR
   Report Blocks may refer.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Measurement Identity Report Block  . . . . . . . . . . . .  3
     1.2.  RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . .  4
     1.3.  Performance Metrics Framework  . . . . . . . . . . . . . .  4
     1.4.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Measurement Identity Block . . . . . . . . . . . . . . . . . .  5
     2.1.  Report Block Structure . . . . . . . . . . . . . . . . . .  5
     2.2.  Definition of Fields in Measurement Identity Report
           Block  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  SDP Signaling  . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  New RTCP XR Block Type value . . . . . . . . . . . . . . .  9
     4.2.  Contact information for registration . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  References .  Changes since last version . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . 11
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     6.2.  Informative 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

1.  Introduction

1.1.  Measurement Identity Report Block

   This draft defines a new block type to augment those defined in
   [RFC3611] for use in a range of RTP applications.  This block type
   does not itself contain any measurement results (metrics).  However,
   this new block type provides information relevant to a measurement
   reported in one or more other block types, including

   o  a tag or key by which other blocks (containing metrics
      information) may refer to this block

   o  the SSRC of the measured stream,

   o  a field for incorporation of an application-specific auxiliary

   o  the extended sequence numbers number of the first packet of the RTP session,

   o  the extended sequence numbers of the first packet of the current
      measurement interval, and the last packet included in the

   o  the duration of the most recent measurement interval and

   o  the duration of the interval applicable to cumulative measurements
      (which may be the duration of the RTP session to date).

   The method for calculation of the extended RTP sequence number is
   provide in [RFC3550].

   This block is intended to provide a single copy of the information
   necessary to relate measurement data in other blocks to the stream,
   and measurement period, to which they refer.  Commonly, multiple
   other small blocks contain measurement data for the same stream and
   period, and it would be a large overhead if all of these blocks
   carried duplicated data for measurement identification.  Other blocks
   make a reference to this block (by tag).

   A Measurement Identity block is associated with the set of RTCP XR
   metrics blocks which share its tag value.  There MAY be several such
   sets in an RTCP packet, up to a limit of 8 arising from the use of
   3-bit tags.  There MAY also be RTCP XR blocks in the packet which are
   not associated with a Measurement Identity block, for example blocks
   which were defined before the Measurement Identity mechanism was
   introduced by this document.

1.2.  RTCP and RTCP XR Reports

   The use of RTCP for reporting is defined in [RFC3550].  [RFC3611]
   defined an extensible structure for reporting using an RTCP Extended
   Report (XR).  This draft defines a new Extended Report block that
   MUST be used as defined in [RFC3550] and [RFC3611].

1.3.  Performance Metrics Framework

   The Performance Metrics Framework [PMOLFRAME] provides guidance on
   the definition and specification of performance metrics.  Metrics
   described in this draft either reference external definitions or
   define metrics generally in accordance with the guidelines in

1.4.  Applicability

   This block provides identification information for members of a
   family of RTCP XR metrics blocks which are designed to use it.  To
   use the mechanism defined here, a metrics block must be in the same
   RTCP packet as the Measurement Identity block and must refer to the
   Measurement Identity block via the 3-bit tag field defined below.

2.  Measurement Identity Block

2.1.  Report Block Structure

        0               1               2               3
        0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
       |     BT=NMI    |0| tag |  fwd resv  |      block length = 7         |
       |                    SSRC of stream source                      |
       |                        sub-identifier                         |
       |           extended            reserved           |         first sequence number (cumulative) seq num         |
       |           extended first sequence number of interval          |
       |                 extended last sequence number                 |
       |          Measurement Duration (Cumulative) (ms)               |
       |           Measurement Duration (Interval) (ms)                |

                     Figure 1: Report Block Structure

2.2.  Definition of Fields in Measurement Identity Report Block

   Bits shown as '0' in the figure SHOULD be set to zero.

   block type (BT): 8 bits

      A Measurement Identity Report Block is identified by the constant

   [Note to RFC Editor: please replace NMI with the IANA provided RTCP
   XR block type for this block.]

   tag: 3 bits

      This field is a tag or key which identifies this Measurement
      Identity block within the scope of an RTCP packet.  If an RTCP
      packet contains more than one Measurement Identity block, each
      Measurement Identity block MUST have a unique tag field to enable
      metrics blocks in the same RTCP packet to refer unambiguously to
      the correct Measurement Identity block.  The 3-bit field allows up
      to 8 Measurement Identity blocks in each RTCP packet.  If
      additional metrics must be sent at a given time, and they require
      more than 8 blocks of Measurement Identity information, then the
      metrics must be sent in multiple RTCP packets.

   Forwarding count (fwd):

   resv: 4 bits

      These bits provide a count of the number of times the block, and
      those blocks which refer to it have been forwarded. are reserved.  They MUST be set to zero by the RTP system which creates the Measurement
      Identity block.  The Forwarding count SHOULD senders.
      They MUST be incremented ignored by any
      RTP system which forwards the block, provided that the operation
      does not cause the Forwarding count to wrap from 0xF to 0x0.
      Then, values of the Forwarding count less than 0xF are
      unambiguous.  An RTP system which receives a block with Forwarding
      count set to 0xF may deduce that the block has been forwarded 15
      or more times. receivers.

   block length: 16 bits

      The length of this report block in 32-bit words minus one.  For
      the Measurement Identity block, the block length is equal to 5. 7.

   SSRC of source: 32 bits

      The SSRC [RFC3550] of the source of the stream being reported.
      Note that the SSRC of the reporting RTP system (the originator of
      the report block) is present in the RTCP XR header defined in
      Section 2 of [RFC3611].

   sub-identifier: 32 bits

      An additional identifier which is useful in the context of a
      specific application, e.g. an MPEG-2 transport identifier [MPEG2].
      Where the identifier is less than 32 bits, the identifier SHOULD
      be mapped into the most significant bits of the field.  If no
      additional identifier is provided, all bits of the field MUST be
      set to zero.  This field MUST be ignored by applications which are
      not configured to make use of it.

   extended first sequence number (cumulative): 32

   reserved: 16 bits

      The extended RTP sequence number of the first received RTP packet
      relevant to cumulative measurements.  Usually this will

      These bits are reserved.  They MUST be the
      extended ignored by receivers.  They
      MUST be set to zero by senders.

   first seq num: 16 bits

      The RTP sequence number of the first received RTP packet of the RTP session.
      session, used to determine the number of packets contributing to
      cumulative measurements.

   extended first sequence number of interval: 32 bits

      The extended RTP sequence number of the first received RTP packet
      of the current measurement interval.

   extended last sequence number: 32 bits
      The extended RTP sequence number of the last received RTP packet
      which contributed to this measurement.

   Measurement Duration (Cumulative) (ms): 32 bits

      The duration in ms of the reporting interval applicable to
      Cumulative reports which use this Measurement Identity block.

   Measurement Duration (Interval) (ms): 32 bits

      The duration in ms of the reporting interval applicable to
      Interval reports which use this Measurement Identity block.

3.  SDP Signaling

   [RFC3611] defines the use of SDP (Session Description Protocol)
   [RFC4566] for signaling the use of XR blocks.  XR blocks MAY be used
   without prior signaling.

   This section augments the

   No additional SDP [RFC4566] attribute "rtcp-xr" defined
   in [RFC3611] by providing a "xr-format" to signal the use of the
   report block signaling is defined in for this document.

   The block.  Instead, the
   need for this block could SHOULD be inferred from a request in SDP
   signalling for a block type (such as [BASICLOSS]) [DISCARD]) which depends on it.  However to remove ambiguity, if SDP is used to signal a desire
   to receive a block type which depends on the Measurement Identity
   block, then the Measurement Identity block itself MUST be signalled
   explicitly in SDP as described here.

   rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF

   (defined in RFC3611)

   xr-format = xr-format / xr-mi-block

   xr-mi-block = "xr-mi"

4.  IANA Considerations

   New block types for RTCP XR are subject to IANA registration.  For
   general guidelines on IANA considerations for RTCP XR, refer to

4.1.  New RTCP XR Block Type value

   This document creates a new assigns the block type within value NMI in the IANA "RTCP XR
   Block Type Registry" called to the Measurement "Measurement Identity Block, and a new
   parameter xr-mi within Block".

   [Note to RFC Editor: please replace NMI with the "RTCP IANA provided RTCP
   XR SDP Parameters Registry". block type for this block.]

4.2.  Contact information for registration

   The contact information for the registration is:

   Geoff Hunt (

   Orion 2 PP3, Adastral Park, Martlesham Heath, Ipswich IP5 3RE, United

5.  Security Considerations

   RTCP reports can contain sensitive information since they can provide
   information about the nature and duration of a session established
   between two or more endpoints.

6.  Changes since last version

   Expanded and clarified IANA Considerations section

   Changed to remove explicit SDP signalling for this block - need for
   block is implicit if a metrics block is requested which depends on
   this block.

   Modified block structure to send first sequence number without
   extension, rather than extend to 32-bit number with leading 16 bits
   set to 0.  These 16 bits are now reserved.  Addresses Colin Perkins'
   comment of 15-Nov-2008

   Removed "forwarding count" field following Colin Perkins' request for
   a use case.  The field had been intended for use by translators to
   establish the "distance" (as a count of forwarding systems) to the
   point at which a measurement was made.  However a recommendation to
   increment the count could have forced forwarding translator devices
   to parse the packet on a slow (CPU) path, possibly compromising RTCP
   measurement of round-trip delay [RFC3550].

7.  References


7.1.  Normative References

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

   [RFC3550]  Schulzrinne, H., "RTP: A Transport Protocol for Real-Time
              Applications", RFC 3550, July 2003.

   [RFC3611]  Friedman, T., "RTP Control Protocol Extended Reports (RTCP
              XR)", RFC 3611, November 2003.

   [RFC4566]  Handley, M., "SDP: Session Description Protocol",
              RFC 4566, July 2006.


7.2.  Informative References


   [DISCARD]  Hunt, G., "RTCP XR Report Block for Measurement Identity", Discard metric
              Reporting", ID draft-ietf-avt-rtcp-xr-meas-identity-00, October 2008. draft-ietf-avt-rtcp-xr-discard-01,
              February 2009.

   [MONARCH]  Hunt, G., "Monitoring Architectures for RTP",
              ID draft-hunt-avt-monarch-01, August 2008.

   [MPEG2]    ISO/IEC, "Standard 13818-1",
              ID draft-ietf-avt-rtcp-xr-meas-identity-00, December 2000.

              Clark, A., "Framework for Performance Metric Development",
              ID draft-ietf-pmol-metrics-framework-00, July 2008.

Authors' Addresses

   Geoff Hunt
   Orion 1 PP9 2 PP3
   Adastral Park
   Martlesham Heath
   Ipswich, Suffolk  IP4 2TH  IP5 3RE
   United Kingdom

   Phone: +44 1473 608325 651704

   Alan Clark
   Telchemy Incorporated
   2905 Premiere Parkway, Suite 280
   Duluth, GA  30097


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at