GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6332

Internet Engineering Task Force (IETF) A. Begen Request for Comments: 6332 E. Friedrich Category: Standards Track Cisco ISSN: 2070-1721 July 2011

            Multicast Acquisition Report Block Type for
         RTP Control Protocol (RTCP) Extended Reports (XRs)

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 can use one or 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 can do a simple
 multicast join (in other cases, it is compelled to do so).  For
 quality reporting, monitoring, and diagnostic 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 the
 Multicast Acquisition (MA) report block, within the framework of RTP
 Control Protocol (RTCP) Extended Reports (XRs) (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 is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6332.

Begen & Friedrich Standards Track [Page 1] RFC 6332 MA Report Block Type for RTCP XR July 2011

Copyright Notice

 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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
 4.  Multicast Acquisition (MA) Report Block  . . . . . . . . . . .  4
   4.1.  Base Report  . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.1.  Status Code Rules for New MA Methods . . . . . . . . .  6
     4.1.2.  Status Code Rules for the RAMS Method  . . . . . . . .  6
   4.2.  Extensions . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.1.  Vendor-Neutral Extensions  . . . . . . . . . . . . . .  7
     4.2.2.  Private Extensions . . . . . . . . . . . . . . . . . . 10
 5.  Session Description Protocol Signaling . . . . . . . . . . . . 10
 6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
 7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.1.  RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 11
   7.2.  RTCP XR SDP Parameter  . . . . . . . . . . . . . . . . . . 12
   7.3.  Multicast Acquisition Method Registry  . . . . . . . . . . 12
   7.4.  Multicast Acquisition Report Block TLV Space Registry  . . 12
   7.5.  Multicast Acquisition Status Code Space Registry . . . . . 13
 8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
 9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
   9.2.  Informative References . . . . . . . . . . . . . . . . . . 15

Begen & Friedrich Standards Track [Page 2] RFC 6332 MA Report Block Type for RTCP XR July 2011

1. Introduction

 The RTP Control Protocol (RTCP) is the out-of-band control protocol
 for applications that use 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 are 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 the data in 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, [RFC6285] 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 RTP Sessions
 (RAMS).  However, depending on the variability in the Source
 Filtering Group Management Protocol (SFGMP) processing times, the
 availability of network resources for rapid acquisition, and the
 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 in 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 the
 Multicast Acquisition (MA) report block, within the framework of RTCP
 XR.  RTP receivers that use the method described in [RFC6285] 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
 that do not use any method but rather do a simple multicast join may
 also use this report.  This way, the multicast service provider can
 quantitatively compare the improvements achieved by different
 methods.

Begen & Friedrich Standards Track [Page 3] RFC 6332 MA Report Block Type for RTCP XR July 2011

2. Requirements Notation

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
 [RFC2119].

3. Definitions

 This document uses the acronyms and definitions from Section 3 of
 [RFC6285].

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 [RFC6285].  Other
 methods that provide rapid acquisition can 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, synchronization
 source (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).
 It is better to send the MA report block after all the necessary
 information is collected and computed.  Partial reporting is
 generally not useful as it cannot give the full picture of the
 multicast acquisition, and it causes additional complexity in terms
 of report block matching and correlation.  The MA report block is
 only sent as a part of an RTCP compound packet, and it is sent in the
 primary multicast session.
 The need for reliability of the MA report block is not any greater
 than other report blocks or types.  If desired, the report block
 could be repeated for redundancy purposes while respecting the RTCP
 scheduling algorithms.
 Following the rules specified in [RFC3550], all integer fields in the
 base report and extensions defined below are carried in network-byte
 order, that is, most significant byte (octet) first, also known as
 big-endian.  Unless otherwise stated, numeric constants are in
 decimal (base 10).

Begen & Friedrich Standards Track [Page 4] RFC 6332 MA Report Block Type for RTCP XR July 2011

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
 o  BT (8 bits): Field that denotes the type for this block format.
    The MA report block is identified by the constant 11.
 o  MA Method (8 bits): 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): Field that denotes
    the SSRC of the primary multicast stream.
 o  Status (16 bits): 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 according to 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.  Section 4.2.2 defines how a vendor defines and
    uses private extensions to convey its messages.
    To indicate use of a private extension, the RTP receiver MUST set
    the Status field to zero.  A private extension MUST NOT be used in
    an XR unless the RTP receiver knows from out-of-band methods that
    the entity that will receive and process the XR understands the
    private extension.
 o  Rsvd. (16 bits): The RTP receiver MUST set this field to zero.
    The recipient MUST ignore this field when received.

Begen & Friedrich Standards Track [Page 5] RFC 6332 MA Report Block Type for RTCP XR July 2011

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

4.1.1. Status Code Rules for New MA Methods

 Different MA methods usually use different status codes, although
 some status codes (e.g., a code indicating that multicast join has
 failed) can be common among multiple MA methods.  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 can generate a status code
 for its multicast acquisition attempt or can 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.  Each MA method needs to outline the rules
 pertaining to its response and status codes so that RTP receiver
 implementations can determine what to report in any given scenario.

4.1.2. Status Code Rules for the RAMS Method

 In this section, we provide the status code rules for the RAMS method
 described in [RFC6285].
 Section 11.6 of [RFC6285] defines several response codes.  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, then the RTP receiver MUST use one of the 1xxx-
 level status codes defined in Section 7.5 of this document.  If the
 RTP receiver receives a 4xx- or 5xx-level response code (indicating
 receiver-side and server-side errors, respectively), then 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.

4.2. Extensions

 To improve the reporting scope, it might be desirable to define new
 fields in the MA report block.  Such fields are to 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.

Begen & Friedrich Standards Track [Page 6] RFC 6332 MA Report Block Type for RTCP XR July 2011

 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 needed for alignment.
 o  Value: Variable-size set of octets that contains the specific
    value for the parameter.
 In the extensions, the Reserved field MUST 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, the RTP receiver MUST place any vendor-
 neutral or private extension after the base report.
    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 need to be registered with
 IANA according to the guidelines provided in Section 7.4.
 This 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 be included.  If
    no multicast packet has been received, this element MUST NOT exist
    in the report block.
    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 the SFGMP
    Join message was sent and the instant the first packet was

Begen & Friedrich Standards Track [Page 7] RFC 6332 MA Report Block Type for RTCP XR July 2011

    received in the multicast session.  If the multicast join was
    successful, this element MUST be included.  If no multicast packet
    has been received, this element MUST NOT exist in the report
    block.
    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 MUST NOT exist in the report block.
    Type: 3
 o  Application Request-to-Presentation 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 media was first presented.  If the RTP
    receiver cannot successfully present the media, this element MUST
    NOT exist in the report block.
    Type: 4
 We next present the TLV elements that can be used when the RTP
 receiver supports and uses the RAMS method described in [RFC6285].
 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 or
 not the RTP receiver receives any packet from the unicast burst
 and/or the primary multicast stream.  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 was sent and the instant the

Begen & Friedrich Standards Track [Page 8] RFC 6332 MA Report Block Type for RTCP XR July 2011

    first RAMS Information message was received in the unicast
    session.  If no such message has been received, this element MUST
    NOT exist in the report block.
    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 was sent and the instant the first burst
    packet was received in the unicast session.  If no burst packet
    has been received, this element MUST NOT exist in the report
    block.
    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 was sent and the instant the
    first RTP packet was received from the primary multicast stream.
    If no such packet has been received, this element MUST NOT exist
    in the report block.
    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 was sent and the instant the
    last burst packet was received in the unicast session.  If no
    burst packet has been received, this element MUST NOT exist in the
    report block.
    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 MUST NOT exist.  If no burst packet has been received
    in the unicast session, the value of this element MUST 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

Begen & Friedrich Standards Track [Page 9] RFC 6332 MA Report Block Type for RTCP XR July 2011

    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 MUST NOT exist in the report block.
    Type: 17

4.2.2. Private Extensions

 It is desirable to allow vendors to use private extensions in TLV
 format.  The range of [128-254] of TLV Types is reserved for private
 extensions.  IANA management for these extensions is unnecessary;
 they are the responsibility of individual vendors.
 Implementations use the structure depicted in Figure 3 for private
 extensions.  Here, the private enterprise numbers are used from
 http://www.iana.org.  This will ensure the uniqueness of the private
 extensions and avoid any collision.
    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

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].  In the
 following ABNF [RFC5234], xr-format is used as defined in [RFC3611].
                  xr-format =/ multicast-acq-ext
                  multicast-acq-ext = "multicast-acq"
 Refer to Section 5.1 of [RFC3611] for a detailed description and the
 full syntax of the 'rtcp-xr' attribute.

Begen & Friedrich Standards Track [Page 10] RFC 6332 MA Report Block Type for RTCP XR July 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 with any
 other RTCP reports if proper protection mechanism(s) are not in
 place.  If desired, similar to other RTCP XRs, the MA reports MAY be
 protected by using Secure RTP (SRTP) and Secure RTP Control Protocol
 (SRTCP) [RFC3711].
 Malicious sniffing or otherwise obtaining MA report blocks can reveal
 performance characteristics of the RTP service and underlying
 network.  This information is mostly available to an observer with
 the ability to capture RTP and RTCP session traffic.  The contents
 and value of any private extension need to be studied when
 considering the necessity to secure the MA reports since application-
 level performance data might be present that is not otherwise
 available to an attacker, as with the required fields and vendor-
 neutral extensions.
 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 can 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 [RFC6285].  Additionally, forged reports could give the
 appearance that rapid acquisition is performing correctly when it is
 in fact failing, or vice versa.  While integrity protection can be
 achieved in different ways, we RECOMMEND the use of SRTCP [RFC3711].

7. IANA Considerations

 The following contact information is provided for all registrations
 in this document:
 Ali Begen
 abegen@cisco.com

7.1. RTCP XR Block Type

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

Begen & Friedrich Standards Track [Page 11] RFC 6332 MA Report Block Type for RTCP XR July 2011

7.2. RTCP XR SDP Parameter

 The SDP [RFC4566] parameter 'multicast-acq' for the 'rtcp-xr'
 attribute has been registered in the RTCP XR SDP Parameters Registry.

7.3. Multicast Acquisition Method Registry

 A new IANA registry for the MA methods has been created.  The
 registry is called the "Multicast Acquisition Method Registry".  This
 registry is to be managed by 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                             [RFC6332]
 1         Simple join (No explicit method)     [RFC6332]
 2         RAMS                                 [RFC6285]
 3-254     Unassigned                   Specification Required
 255       Reserved                             [RFC6332]
 The MA Method values 0 and 255 are reserved for future use.
 Any registration for an unassigned 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 how the MA method works.

7.4. Multicast Acquisition Report Block TLV Space Registry

 A new IANA TLV space registry for the MA report block extensions has
 been created.  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:

Begen & Friedrich Standards Track [Page 12] RFC 6332 MA Report Block Type for RTCP XR July 2011

 Type    Description                                        Reference
 ------- -------------------------------------------------- ---------
 0       Reserved                                           [RFC6332]
 1       RTP Seqnum of the First Multicast Packet           [RFC6332]
 2       SFGMP Join Time                                    [RFC6332]
 3       Application Request-to-Multicast Delta Time        [RFC6332]
 4       Application Request-to-Presentation Delta Time     [RFC6332]
 5-10    Unassigned                            Specification Required
 11      Application Request-to-RAMS Request Delta Time     [RFC6332]
 12      RAMS Request-to-RAMS Information Delta Time        [RFC6332]
 13      RAMS Request-to-Burst Delta Time                   [RFC6332]
 14      RAMS Request-to-Multicast Delta Time               [RFC6332]
 15      RAMS Request-to-Burst-Completion Delta Time        [RFC6332]
 16      Number of Duplicate Packets                        [RFC6332]
 17      Size of Burst-to-Multicast Gap                     [RFC6332]
 18-127  Unassigned                            Specification Required
 128-254 Reserved for private extensions                    [RFC6332]
 255     Reserved                                           [RFC6332]
 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 is interpreted.

7.5. Multicast Acquisition Status Code Space Registry

 A new IANA TLV space registry for the status codes has been created.
 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 [RFC6285].  When registering new status codes for
 the existing MA methods or newly defined MA methods, registrants are

Begen & Friedrich Standards Track [Page 13] RFC 6332 MA Report Block Type for RTCP XR July 2011

 encouraged to allocate sufficient continuous space.  Note that
 because of the limited space, not every MA method can be assigned
 1000 different values for its status codes.
 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 [RFC6332]
 1          Multicast join was successful                    [RFC6332]
 2          Multicast join has failed                        [RFC6332]
 3          A presentation error has occurred                [RFC6332]
 4          An unspecified RTP receiver internal error has
            occurred                                         [RFC6332]
 5-1000     Unassigned
 1001       RAMS has been successfully completed             [RFC6332]
 1002       No RAMS-R message has been sent                  [RFC6332]
 1003       Invalid RAMS-I message syntax                    [RFC6332]
 1004       RAMS-I message has timed out                     [RFC6332]
 1005       RAMS unicast burst has timed out                 [RFC6332]
 1006       An unspecified RTP receiver internal error has
            occurred during RAMS                             [RFC6332]
 1007       A presentation error has occurred during RAMS    [RFC6332]
 1008-65534 Unassigned
 65535      Reserved                                         [RFC6332]
 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 is interpreted.

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 Standards Track [Page 14] RFC 6332 MA Report Block Type for RTCP XR July 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.
 [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
            Norrman, "The Secure Real-time Transport Protocol (SRTP)",
            RFC 3711, March 2004.
 [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.
 [RFC6285]  Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
            "Unicast-Based Rapid Acquisition of Multicast RTP
            Sessions", RFC 6285, June 2011.

9.2. Informative References

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

Begen & Friedrich Standards Track [Page 15] RFC 6332 MA Report Block Type for RTCP XR July 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 Standards Track [Page 16]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6332.txt · Last modified: 2011/07/29 21:55 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki