[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-avt-multicast-acq-rtcp-xr) 00 01 02 03 04 05 06 RFC 6332

AVT                                                             A. Begen
Internet-Draft                                              E. Friedrich
Intended status:  Standards Track                                  Cisco
Expires:  October 1, 2011                                 March 30, 2011


Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP)
                         Extended Reports (XRs)
               draft-ietf-avtext-multicast-acq-rtcp-xr-01

Abstract

   In most RTP-based multicast applications, the RTP source sends inter-
   related data.  Due to this interdependency, randomly joining RTP
   receivers usually cannot start consuming the multicast data right
   after they join the session.  Thus, they often experience a random
   acquisition delay.  An RTP receiver may use one ore more different
   approaches to achieve rapid acquisition.  Yet, due to various
   factors, performance of the rapid acquisition methods usually varies.
   Furthermore, in some cases the RTP receiver may (or may have to) do a
   simple multicast join.  For quality reporting, monitoring and
   diagnostics purposes, it is important to collect detailed information
   from the RTP receivers about their acquisition and presentation
   experiences.  This document addresses this issue by defining a new
   report block type, called Multicast Acquisition (MA) Report Block,
   within the framework of RTP Control Protocol (RTCP) Extended Reports
   (XR) (RFC 3611).  This document also defines the necessary signaling
   of the new MA report block type in the Session Description Protocol
   (SDP).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on October 1, 2011.

Copyright Notice



Begen & Friedrich        Expires October 1, 2011                [Page 1]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


   Copyright (c) 2011 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
   (http://trustee.ietf.org/license-info) 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Multicast Acquisition (MA) Report Block  . . . . . . . . . . .  6
     4.1.  Base Report  . . . . . . . . . . . . . . . . . . . . . . .  6
       4.1.1.  Status Code Rules  . . . . . . . . . . . . . . . . . .  7
     4.2.  Extensions . . . . . . . . . . . . . . . . . . . . . . . .  8
       4.2.1.  Vendor-Neutral Extensions  . . . . . . . . . . . . . .  9
       4.2.2.  Private Extensions . . . . . . . . . . . . . . . . . . 11
   5.  Session Description Protocol Signaling . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 15
     7.2.  RTCP XR SDP Parameter  . . . . . . . . . . . . . . . . . . 15
     7.3.  Multicast Acquisition Method Registry  . . . . . . . . . . 15
     7.4.  Multicast Acquisition Report Block TLV Space Registry  . . 16
     7.5.  Multicast Acquisition Status Code Space Registry . . . . . 17
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21













Begen & Friedrich        Expires October 1, 2011                [Page 2]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


1.  Introduction

   RTP Control Protocol (RTCP) is the out-of-band control protocol for
   the applications that are using the Real-time Transport Protocol
   (RTP) for media transport [RFC3550].  In addition to providing
   minimal control functionality to RTP entities, RTCP also enables a
   basic level monitoring of RTP sessions via sender and receiver
   reports.  More statistically detailed monitoring as well as
   application-specific monitoring is usually achieved through the RTCP
   Extended Reports (XRs) [RFC3611].

   In most RTP-based multicast applications such as the ones carrying
   video content, the RTP source sends inter-related data.
   Consequently, the RTP application may not be able to decode and
   present the data in an RTP packet before decoding one or more earlier
   RTP packets and/or before acquiring some Reference Information about
   the content itself.  Thus, RTP receivers that are randomly joining a
   multicast session often experience a random acquisition delay.  In
   order to reduce this delay, [I-D.ietf-avt-rapid-acquisition-for-rtp]
   proposes an approach where an auxiliary unicast RTP session is
   established between a retransmission server and the joining RTP
   receiver.  Over this unicast RTP session, the retransmission server
   provides the Reference Information, which is all the information the
   RTP receiver needs to rapidly acquire the multicast stream.  This
   method is referred to as the Rapid Acquisition of Multicast Sessions
   (RAMS).  However, depending on the variability in the Source
   Filtering Group Management Protocol (SFGMP) processing times,
   availability of network resources for rapid acquisition and nature of
   the RTP data, not all RTP receivers can acquire the multicast stream
   in the same amount of time.  The performance of rapid acquisition may
   vary not only for different RTP receivers but also over time.

   To increase the visibility of the multicast service provider into its
   network, to diagnose slow multicast acquisition issues and to collect
   the acquisition experiences of the RTP receivers, this document
   defines a new report block type, which is called Multicast
   Acquisition (MA) Report Block, within the framework of RTCP XR.  RTP
   receivers that are using the method described in
   [I-D.ietf-avt-rapid-acquisition-for-rtp] may use this report every
   time they join a new multicast RTP session.  RTP receivers that use a
   different method for rapid acquisition or those do not use any method
   but rather do a simple multicast join may also use this report to
   collect information.  This way, the multicast service provider can
   quantitatively compare the improvements achieved by different
   methods.






Begen & Friedrich        Expires October 1, 2011                [Page 3]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


2.  Requirements Notation

   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 [RFC2119].














































Begen & Friedrich        Expires October 1, 2011                [Page 4]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


3.  Definitions

   This document uses the following acronyms and definitions from
   [I-D.ietf-avt-rapid-acquisition-for-rtp]:

   (Primary) Multicast Session:  The multicast session to which RTP
   receivers can join at a random point in time.

   Primary Multicast RTP Session:  The multicast RTP session an RTP
   receiver is interested in acquiring.

   Primary Multicast (RTP) Streams:  The RTP stream(s) carried in the
   primary multicast RTP session.

   Source Filtering Group Management Protocol (SFGMP):  Following the
   definition in [RFC4604], SFGMP refers to the Internet Group
   Management Protocol (IGMP) version 3 [RFC3376] and the Multicast
   Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and
   IPv6 networks, respectively.  However, the report block type
   introduced in this document does not depend on a specific version of
   either of these group management protocols.  In the remainder of this
   document, SFGMP will refer to any group management protocol that has
   Join and Leave functionalities.

   Retransmission (Burst) Packet:  An RTP packet that is formatted as
   defined in [RFC4588].

   Reference Information:  The set of certain media content and metadata
   information that is sufficient for an RTP receiver to start usefully
   consuming a media stream.  The meaning, format and size of this
   information are specific to the application and are out of scope of
   this document.

   (Unicast) Burst (Stream):  A unicast stream of RTP retransmission
   packets that enable an RTP receiver to rapidly acquire the Reference
   Information associated with a primary multicast stream.  Each burst
   stream is identified by its SSRC identifier that is unique in the
   primary multicast RTP session.  The burst streams are typically
   transmitted at an accelerated rate.

   Retransmission Server (RS):  The RTP/RTCP endpoint that can generate
   the retransmission packets and the burst streams.  RS may also
   generate other non-retransmission packets to aid the rapid
   acquisition process.







Begen & Friedrich        Expires October 1, 2011                [Page 5]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


4.  Multicast Acquisition (MA) Report Block

   This section defines the format of the MA report block.  The base
   report is payload-independent.  An extension mechanism is provided
   where further optional payload-independent and payload-specific
   information can be included in the report as desired.

   The optional extensions that are defined in this document are
   primarily developed for the method presented in
   [I-D.ietf-avt-rapid-acquisition-for-rtp].  Other methods that provide
   rapid acquisition MAY define their own extensions to be used in the
   MA report block.

   The packet format for the RTCP XR is defined in Section 2 of
   [RFC3611].  Each XR packet has a fixed-length field for version,
   padding, reserved bits, payload type (PT), length, SSRC of packet
   sender as well as a variable-length field for report blocks.  In the
   XR packets, the PT field is set to XR (207).

   The MA report block is better to be sent after all the necessary
   information is collected and computed.  Partial reporting is
   generally not useful as it may not give the full picture of the
   multicast acquisition, and causes additional complexity in terms of
   report block matching and correlation.  The MA report block SHOULD
   only be sent as a part of an RTCP compound packet, and it is sent in
   the primary multicast session.

   The reliability of the MA report block is not any more essential than
   other report blocks or types.  If desired, the report block could be
   repeated for redundancy purposes while respecting to the RTCP
   scheduling algorithms.

4.1.  Base Report

   The base report format is shown in Figure 1.


      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=11     |   MA Method   |         Block Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              SSRC of the Primary Multicast Stream             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Status            |             Rsvd.             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 1: Base report format for the MA report block



Begen & Friedrich        Expires October 1, 2011                [Page 6]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


   o  BT (8 bits):  Mandatory field that denotes the type for this block
      format.  The MA report block is identified by the constant 11.

   o  MA Method (8 bits):  Mandatory field that denotes the type of the
      MA method (e.g., simple join, RAMS, etc.).  See Section 7.3 for
      the values registered with IANA.

   o  Block Length (16 bits):  The length of this report block,
      including the header, in 32-bit words minus one.

   o  SSRC of the Primary Multicast Stream (32 bits):  Mandatory field
      that denotes the SSRC of the primary multicast stream.

   o  Status (16 bits):  Mandatory field that denotes the status code
      for the MA operation.

      This document defines several status codes and registers them with
      IANA in Section 7.5.  If a new vendor-neutral status code will be
      defined, it MUST be registered with IANA through the guidelines
      specified in Section 7.5.  If the new status code is intended to
      be used privately by a vendor, there is no need for IANA
      management.  Instead, the vendor MUST use the private extension
      mechanism (Section 4.2.2) to convey its message and MUST indicate
      this by putting zero in the Status field.

   o  Rsvd. (16 bits):  This field SHALL be set to 0 and ignored on
      reception.

   If the multicast join was successful meaning that at least one
   multicast packet has been received, some additional information MUST
   be appended to the base report as will be described in Section 4.2.1.

4.1.1.  Status Code Rules

   Different MA methods usually use different status codes, although
   some status codes (e.g., a code indicating that multicast join has
   failed) may apply to more than one MA method.  However, the status
   code reported in the base report MUST always be within the scope of
   the particular MA method specified in the MA Method field.

   In certain MA methods, the RTP receiver may generate a status code
   for its multicast acquisition attempt, or may be told by another
   network element or RTP endpoint what the current status is via a
   response code.  In such cases, the RTP receiver MAY report the value
   of the received response code as its status code if the response code
   has a higher priority.  It is RECOMMENDED that each MA method
   outlines the rules pertaining to its response and status codes so
   that RTP receiver implementations can determine what to report in any



Begen & Friedrich        Expires October 1, 2011                [Page 7]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


   given scenario.  Below, we provide these rules for the RAMS method
   described in [I-D.ietf-avt-rapid-acquisition-for-rtp].

   Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines
   several response codes for its MA method.  The 1xx and 2xx-level
   response codes are informational and success response codes,
   respectively.  If the RTP receiver receives a 1xx or 2xx-level
   response code, it MUST use one of the 1xxx-level status codes defined
   in Section 7.5 of this document.  The RTP receiver may also receive a
   4xx or 5xx-level response code (indicating receiver-side and server-
   side errors, respectively).  In that case, the RTP receiver MUST use
   the response code as its status code.  In other words, the 4xx and
   5xx-level response codes have a higher priority than the 1xxx-level
   status codes.  The 5xx-level response codes have a higher priority
   than the 4xx-level response codes and MUST be reported in the base
   report in case the RTP receiver receives both 4xx and 5xx-level
   response codes (in different RAMS-I messages) during the same RAMS
   session.

4.2.  Extensions

   To improve the reporting scope, it might be desirable to define new
   fields in the MA report block.  Such fields MUST be encoded as TLV
   elements as described below and sketched in Figure 2:

   o  Type:  A single-octet identifier that defines the type of the
      parameter represented in this TLV element.

   o  Length:  A two-octet field that indicates the length (in octets)
      of the TLV element excluding the Type and Length fields, and the
      8-bit Reserved field between them.  Note that this length does not
      include any padding that is required for alignment.

   o  Value:  Variable-size set of octets that contains the specific
      value for the parameter.

   In the extensions, the Reserved field SHALL be set to zero and
   ignored on reception.  If a TLV element does not fall on a 32-bit
   boundary, the last word MUST be padded to the boundary using further
   bits set to zero.

   In the MA report block, any vendor-neutral or private extension MUST
   be placed after the base report.








Begen & Friedrich        Expires October 1, 2011                [Page 8]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |   Reserved    |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                             Value                             :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: Structure of a TLV element

4.2.1.  Vendor-Neutral Extensions

   If the goal in defining new TLV elements is to extend the report
   block in a vendor-neutral manner, they MUST be registered with IANA
   through the guidelines provided in Section 7.4.

   The current document defines several vendor-neutral extensions.
   First, we present the TLV elements that can be used by any RTP-based
   multicast application.

   o  RTP Seqnum of the First Multicast Packet (16 bits):  TLV element
      that specifies the RTP sequence number of the first multicast
      packet received for the primary multicast stream.  If the
      multicast join was successful, this element MUST exist.  If no
      multicast packet has been received, this element SHALL NOT exist.

      Type:  1

   o  SFGMP Join Time (32 bits):  TLV element that denotes the greater
      of zero or the time difference (in ms) between the instant SFGMP
      Join message has been sent and the instant the first packet was
      received in the multicast session.  If the multicast join was
      successful, this element MUST exist.  If no multicast packet has
      been received, this element SHALL NOT exist.

      Type:  2

   o  Application Request-to-Multicast Delta Time (32 bits):  Optional
      TLV element that denotes the time difference (in ms) between the
      instant the application became aware it would join a new multicast
      session and the instant the first RTP packet was received from the
      primary multicast stream.  If no such packet has been received,
      this element SHALL NOT exist.

      Type:  3

   o  Application Request-to-Presentation Delta Time (32 bits):
      Optional TLV element that denotes the time difference (in ms)



Begen & Friedrich        Expires October 1, 2011                [Page 9]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


      between the instant the application became aware it would join a
      new multicast session and the instant the media is first
      presented.  If the RTP receiver cannot successfully present the
      media, this element SHALL NOT exist.

      Type:  4

   We next present the TLV elements that can be used when the RTP
   receiver supports and uses the RAMS method described in
   [I-D.ietf-avt-rapid-acquisition-for-rtp].  However, if the RTP
   receiver does not send a rapid acquisition request, the following TLV
   elements MUST NOT exist in the MA report block.  Some elements may or
   may not exist depending on whether the RTP receiver receives any
   packet from the unicast burst and/or the primary multicast stream or
   not.  These are explained below.

   o  Application Request-to-RAMS Request Delta Time (32 bits):
      Optional TLV element that denotes the time difference (in ms)
      between the instant the application became aware it would request
      a rapid acquisition and the instant the rapid acquisition request
      was actually sent by the application.

      Type:  11

   o  RAMS Request-to-RAMS Information Delta Time (32 bits):  Optional
      TLV element that denotes the time difference (in ms) between the
      instant the rapid acquisition request has been sent and the
      instant the first RAMS Information message was received in the
      unicast session.  If no such message has been received, this
      element SHALL NOT exist.

      Type:  12

   o  RAMS Request-to-Burst Delta Time (32 bits):  Optional TLV element
      that denotes the time difference (in ms) between the instant the
      rapid acquisition request has been sent and the instant the first
      burst packet was received in the unicast session.  If no burst
      packet has been received, this element SHALL NOT exist.

      Type:  13

   o  RAMS Request-to-Multicast Delta Time (32 bits):  Optional TLV
      element that denotes the time difference (in ms) between the
      instant the rapid acquisition request has been sent and the
      instant the first RTP packet was received from the primary
      multicast stream.  If no such packet has been received, this
      element SHALL NOT exist.




Begen & Friedrich        Expires October 1, 2011               [Page 10]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


      Type:  14

   o  RAMS Request-to-Burst-Completion Delta Time (32 bits):  Optional
      TLV element that denotes the time difference (in ms) between the
      instant the rapid acquisition request has been sent and the
      instant the last burst packet was received in the unicast session.
      If no burst packet has been received, this element SHALL NOT
      exist.

      Type:  15

   o  Number of Duplicate Packets (32 bits):  Optional TLV element that
      denotes the number of duplicate packets due to receiving the same
      packet in both unicast and primary multicast RTP sessions.  If no
      RTP packet has been received from the primary multicast stream,
      this element SHALL NOT exist.  If no burst packet has been
      received in the unicast session, the value of this element SHALL
      be set to zero.

      Type:  16

   o  Size of Burst-to-Multicast Gap (32 bits):  Optional TLV element
      that denotes the greater of zero or the difference between the
      sequence number of the first multicast packet (received from the
      primary multicast stream) and the sequence number of the last
      burst packet minus 1 (considering the wrapping of the sequence
      numbers).  If no burst packet has been received in the unicast
      session or no RTP packet has been received from the primary
      multicast stream, this element SHALL NOT exist.

      Type:  17

4.2.2.  Private Extensions

   It is desirable to allow vendors to use private extensions in TLV
   format.  For interoperability, such extensions MUST NOT collide with
   each other.

   The range of [128-254] of TLV Types is reserved for private
   extensions.  IANA management for these extensions is unnecessary and
   they are the responsibility of individual vendors.

   The structure that MUST be used for the private extensions is
   depicted in Figure 3.  Here, the private enterprise numbers are used
   from http://www.iana.org/assignments/enterprise-numbers.  This will
   ensure the uniqueness of the private extensions and avoid any
   collision.




Begen & Friedrich        Expires October 1, 2011               [Page 11]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |   Reserved    |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Enterprise Number                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                             Value                             :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: Structure of a private extension








































Begen & Friedrich        Expires October 1, 2011               [Page 12]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


5.  Session Description Protocol Signaling

   A new unilateral parameter is defined for the MA report block to be
   used with the Session Description Protocol (SDP) [RFC4566] using the
   Augmented Backus-Naur Form (ABNF) [RFC5234].  It has the following
   syntax within the 'rtcp-xr' attribute [RFC3611]:

                    multicast-acq-ext = "multicast-acq"


                                 Figure 4

   Refer to Section 5.1 of [RFC3611] for a detailed description and the
   full syntax of the "rtcp-xr" attribute.  The "multicast-acq-ext"
   parameter is compatible with the definition of "format-ext" in the
   "rtcp-xr" attribute.



































Begen & Friedrich        Expires October 1, 2011               [Page 13]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


6.  Security Considerations

   The security considerations of [RFC3611] apply in this document as
   well.

   The information contained in MA reports could be stolen as any other
   RTCP reports if proper protection mechanism(s) are not in place.  If
   desired, similar to other RTCP XR reports, the MA reports MAY be
   protected by using Secure RTP (SRTP) and Secure RTP Control Protocol
   (SRTCP) [RFC3711].

   Using the MA reports to provide feedback into the acquisition of the
   multicast streams can introduce possible additional security
   implications.  If a forged or otherwise modified MA report is
   received for an earlier acquisition attempt, invalid data may be used
   as input in later rapid acquisition attempts.  For example,
   incorrectly small SFGMP join times could cause the unicast burst to
   be too short, leading to gaps in sequence numbers in the approach
   discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp].  Additionally,
   forged reports could give the appearance that rapid acquisition is
   performing correctly, when it is in fact failing, or vice versa.
   However, the MA reports are believed not to introduce any additional
   risks from a confidentiality viewpoint.




























Begen & Friedrich        Expires October 1, 2011               [Page 14]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


7.  IANA Considerations

   The following contact information shall be used for all registrations
   in this document:

   Ali Begen
   abegen@cisco.com

   Note to the RFC Editor:  In the following, please replace "XXXX" with
   the number of this document prior to publication as an RFC.

7.1.  RTCP XR Block Type

   Type value 11 has been pre-registered with IANA for the "Multicast
   Acquisition Report Block" in the RTCP XR Block Type Registry.

7.2.  RTCP XR SDP Parameter

   This document registers the SDP [RFC4566] parameter 'multicast-acq'
   for the 'rtcp-xr' attribute in the RTCP XR SDP Parameters Registry.

7.3.  Multicast Acquisition Method Registry

   This document creates a new IANA registry for the MA methods.  The
   registry is called the Multicast Acquisition Method Registry.  This
   registry is to be managed by the IANA according to the Specification
   Required policy of [RFC5226].

   The length of the MA Method field is a single octet, allowing 256
   values.  The registry is initialized with the following entries:


   MA Method Description                          Reference
   --------- ------------------------------------ -------------
   0         Reserved                             [RFCXXXX]
   1         Simple join (No explicit method)     [RFCXXXX]
   2         RAMS  [I-D.ietf-avt-rapid-acquisition-for-rtp]
   3-254                             Specification Required
   255       Reserved                             [RFCXXXX]


   The MA Method values 0 and 255 are reserved for future use.

   Any registration for an unassigned value needs to contain the
   following information:






Begen & Friedrich        Expires October 1, 2011               [Page 15]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


   o  Contact information of the one doing the registration, including
      at least name, address, and email.

   o  A detailed description of how the MA method works.

7.4.  Multicast Acquisition Report Block TLV Space Registry

   This document creates a new IANA TLV space registry for the MA report
   block extensions.  The registry is called the Multicast Acquisition
   Report Block TLV Space Registry.  This registry is to be managed by
   the IANA according to the Specification Required policy of [RFC5226].

   The length of the Type field in the TLV elements is a single octet,
   allowing 256 values.  The registry is initialized with the following
   entries:


   Type Description                                        Reference
   ---- -------------------------------------------------- -------------
   1    RTP Seqnum of the First Multicast Packet           [RFCXXXX]
   2    SFGMP Join Time                                    [RFCXXXX]
   3    Application Request-to-Multicast Delta Time        [RFCXXXX]
   4    Application Request-to-Presentation Delta Time     [RFCXXXX]
   11   Application Request-to-RAMS Request Delta Time     [RFCXXXX]
   12   RAMS Request-to-RAMS Information Delta Time        [RFCXXXX]
   13   RAMS Request-to-Burst Delta Time                   [RFCXXXX]
   14   RAMS Request-to-Multicast Delta Time               [RFCXXXX]
   15   RAMS Request-to-Burst-Completion Delta Time        [RFCXXXX]
   16   Number of Duplicate Packets                        [RFCXXXX]
   17   Size of Burst-to-Multicast Gap                     [RFCXXXX]


   The Type values 0 and 255 are reserved for future use.  The Type
   values between (and including) 128 and 254 are reserved for private
   extensions.

   Any registration for an unassigned Type value needs to contain the
   following information:

   o  Contact information of the one doing the registration, including
      at least name, address, and email.

   o  A detailed description of what the new TLV element represents and
      how it shall be interpreted.







Begen & Friedrich        Expires October 1, 2011               [Page 16]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


7.5.  Multicast Acquisition Status Code Space Registry

   This document creates a new IANA TLV space registry for the status
   codes.  The registry is called the Multicast Acquisition Status Code
   Space Registry.  This registry is to be managed by the IANA according
   to the Specification Required policy of [RFC5226].

   The length of the Status field is two octets, allowing 65536 codes.
   However, the status codes have been registered to allow for an easier
   classification.  For example, the values between (and including) 1
   and 1000 are primarily used by the MA method of simple join.  The
   values between (and including) 1001 and 2000 are used by the MA
   method described in [I-D.ietf-avt-rapid-acquisition-for-rtp].  When
   registering new status codes for the existing MA methods or newly
   defined MA methods, a similar classification scheme is encouraged to
   be followed.

   The Status code 65535 is reserved for future use.  The registry is
   initialized with the following entries:


  Code  Description                                        Reference
  ----- -------------------------------------------------- -------------
  0     A private status code is included in the message   [RFCXXXX]

  1     Multicast join was successful                      [RFCXXXX]
  2     Multicast join has failed                          [RFCXXXX]
  3     A presentation error has occurred                  [RFCXXXX]
  4     An unspecified RR internal error has occurred      [RFCXXXX]

  1001  RAMS has been successfully completed               [RFCXXXX]
  1002  No RAMS-R message has been sent                    [RFCXXXX]
  1003  Invalid RAMS-I message syntax                      [RFCXXXX]
  1004  RAMS-I message has timed out                       [RFCXXXX]
  1005  RAMS unicast burst has timed out                   [RFCXXXX]
  1006  An unspecified RR internal error has occurred
        during RAMS                                        [RFCXXXX]
  1007  A presentation error has occurred during RAMS      [RFCXXXX]


   Any registration for an unassigned Status code needs to contain the
   following information:

   o  Contact information of the one doing the registration, including
      at least name, address, and email.

   o  A detailed description of what the new Status code describes and
      how it shall be interpreted.



Begen & Friedrich        Expires October 1, 2011               [Page 17]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


8.  Acknowledgments

   This specification has greatly benefited from discussions with
   Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran, Tom
   Van Caenegem and many others.  The authors would like to thank each
   of these individuals for their contributions.













































Begen & Friedrich        Expires October 1, 2011               [Page 18]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


9.  References

9.1.  Normative References

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

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

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

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

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

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              July 2006.

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

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

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

9.2.  Informative References

   [I-D.ietf-avt-rapid-acquisition-for-rtp]
              Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
              Based Rapid Acquisition of Multicast RTP Sessions",
              draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in
              progress), November 2010.



Begen & Friedrich        Expires October 1, 2011               [Page 19]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


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
















































Begen & Friedrich        Expires October 1, 2011               [Page 20]

Internet-Draft      MA Report Block Type for RTCP XR          March 2011


Authors' Addresses

   Ali Begen
   Cisco
   181 Bay Street
   Toronto, ON  M5J 2T3
   Canada

   Email:  abegen@cisco.com


   Eric Friedrich
   Cisco
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   USA

   Email:  efriedri@cisco.com

































Begen & Friedrich        Expires October 1, 2011               [Page 21]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/