draft-ietf-avtext-multicast-acq-rtcp-xr-04.txt   draft-ietf-avtext-multicast-acq-rtcp-xr-05.txt 
AVT A. Begen AVT A. Begen
Internet-Draft E. Friedrich Internet-Draft E. Friedrich
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: October 14, 2011 April 12, 2011 Expires: November 27, 2011 May 26, 2011
Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP)
Extended Reports (XRs) Extended Reports (XRs)
draft-ietf-avtext-multicast-acq-rtcp-xr-04 draft-ietf-avtext-multicast-acq-rtcp-xr-05
Abstract Abstract
In most RTP-based multicast applications, the RTP source sends inter- In most RTP-based multicast applications, the RTP source sends inter-
related data. Due to this interdependency, randomly joining RTP related data. Due to this interdependency, randomly joining RTP
receivers usually cannot start consuming the multicast data right receivers usually cannot start consuming the multicast data right
after they join the session. Thus, they often experience a random after they join the session. Thus, they often experience a random
acquisition delay. An RTP receiver can use one ore more different acquisition delay. An RTP receiver can use one or more different
approaches to achieve rapid acquisition. Yet, due to various approaches to achieve rapid acquisition. Yet, due to various
factors, performance of the rapid acquisition methods usually varies. factors, performance of the rapid acquisition methods usually varies.
Furthermore, in some cases the RTP receiver can do a simple multicast Furthermore, in some cases the RTP receiver can do a simple multicast
join (in other cases it is compelled to do so). For quality join (in other cases it is compelled to do so). For quality
reporting, monitoring and diagnostics purposes, it is important to reporting, monitoring and diagnostics purposes, it is important to
collect detailed information from the RTP receivers about their collect detailed information from the RTP receivers about their
acquisition and presentation experiences. This document addresses acquisition and presentation experiences. This document addresses
this issue by defining a new report block type, called Multicast this issue by defining a new report block type, called Multicast
Acquisition (MA) Report Block, within the framework of RTP Control Acquisition (MA) Report Block, within the framework of RTP Control
Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 14, 2011. This Internet-Draft will expire on November 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 24 skipping to change at page 2, line 24
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 6 4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 6
4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Status Code Rules for New MA Methods . . . . . . . . . 7 4.1.1. Status Code Rules for New MA Methods . . . . . . . . . 8
4.1.2. Status Code Rules for the RAMS Method . . . . . . . . 8 4.1.2. Status Code Rules for the RAMS Method . . . . . . . . 8
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 9 4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 9
4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 11 4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 12
5. Session Description Protocol Signaling . . . . . . . . . . . . 13 5. Session Description Protocol Signaling . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 15 7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 15
7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 15 7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 15
7.3. Multicast Acquisition Method Registry . . . . . . . . . . 15 7.3. Multicast Acquisition Method Registry . . . . . . . . . . 15
7.4. Multicast Acquisition Report Block TLV Space Registry . . 16 7.4. Multicast Acquisition Report Block TLV Space Registry . . 16
7.5. Multicast Acquisition Status Code Space Registry . . . . . 17 7.5. Multicast Acquisition Status Code Space Registry . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
RTP Control Protocol (RTCP) is the out-of-band control protocol for RTP Control Protocol (RTCP) is the out-of-band control protocol for
the applications that are using the Real-time Transport Protocol the applications that are using the Real-time Transport Protocol
(RTP) for media transport [RFC3550]. In addition to providing (RTP) for media transport [RFC3550]. In addition to providing
minimal control functionality to RTP entities, RTCP also enables a minimal control functionality to RTP entities, RTCP also enables a
basic level monitoring of RTP sessions via sender and receiver basic level monitoring of RTP sessions via sender and receiver
reports. More statistically detailed monitoring as well as reports. More statistically detailed monitoring as well as
application-specific monitoring is usually achieved through the RTCP application-specific monitoring is usually achieved through the RTCP
skipping to change at page 4, line 8 skipping to change at page 4, line 8
time they join a new multicast RTP session. RTP receivers that use a 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 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 but rather do a simple multicast join may also use this report to
collect information. This way, the multicast service provider can collect information. This way, the multicast service provider can
quantitatively compare the improvements achieved by different quantitatively compare the improvements achieved by different
methods. methods.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
3. Definitions 3. Definitions
This document uses the following acronyms and definitions from This document uses the acronyms and definitions from Section 3 of
[I-D.ietf-avt-rapid-acquisition-for-rtp]: [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.
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 Section 4 of [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 Synchronization Source (SSRC) identifier
that is unique in the primary multicast RTP session.
Retransmission Server (RS): The RTP/RTCP endpoint that can generate
the retransmission packets and the burst streams. The RS may also
generate other non-retransmission packets to aid the rapid
acquisition process.
4. Multicast Acquisition (MA) Report Block 4. Multicast Acquisition (MA) Report Block
This section defines the format of the MA report block. The base This section defines the format of the MA report block. The base
report is payload-independent. An extension mechanism is provided report is payload-independent. An extension mechanism is provided
where further optional payload-independent and payload-specific where further optional payload-independent and payload-specific
information can be included in the report as desired. information can be included in the report as desired.
The optional extensions that are defined in this document are The OPTIONAL extensions that are defined in this document are
primarily developed for the method presented in primarily developed for the method presented in
[I-D.ietf-avt-rapid-acquisition-for-rtp]. Other methods that provide [I-D.ietf-avt-rapid-acquisition-for-rtp]. Other methods that provide
rapid acquisition can define their own extensions to be used in the rapid acquisition can define their own extensions to be used in the
MA report block. MA report block.
The packet format for the RTCP XR is defined in Section 2 of The packet format for the RTCP XR is defined in Section 2 of
[RFC3611]. Each XR packet has a fixed-length field for version, [RFC3611]. Each XR packet has a fixed-length field for version,
padding, reserved bits, payload type (PT), length, SSRC of packet padding, reserved bits, payload type (PT), length, SSRC of packet
sender as well as a variable-length field for report blocks. In the sender as well as a variable-length field for report blocks. In the
XR packets, the PT field is set to XR (207). XR packets, the PT field is set to XR (207).
skipping to change at page 6, line 37 skipping to change at page 6, line 37
multicast acquisition, and causes additional complexity in terms of multicast acquisition, and causes additional complexity in terms of
report block matching and correlation. The MA report block is only 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 sent as a part of an RTCP compound packet, and it is sent in the
primary multicast session. primary multicast session.
The need for reliability of the MA report block is not any greater The need for reliability of the MA report block is not any greater
than other report blocks or types. If desired, the report block than other report blocks or types. If desired, the report block
could be repeated for redundancy purposes while respecting to the could be repeated for redundancy purposes while respecting to the
RTCP scheduling algorithms. 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).
4.1. Base Report 4.1. Base Report
The base report format is shown in Figure 1. The base report format is shown in Figure 1.
0 1 2 3 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 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 | | BT=11 | MA Method | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of the Primary Multicast Stream | | SSRC of the Primary Multicast Stream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Rsvd. | | Status | Rsvd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Base report format for the MA report block Figure 1: Base report format for the MA report block
o BT (8 bits): Mandatory field that denotes the type for this block o BT (8 bits): Field that denotes the type for this block format.
format. The MA report block is identified by the constant 11. The MA report block is identified by the constant 11.
o MA Method (8 bits): Mandatory field that denotes the type of the o MA Method (8 bits): Field that denotes the type of the MA method
MA method (e.g., simple join, RAMS, etc.). See Section 7.3 for (e.g., simple join, RAMS, etc.). See Section 7.3 for the values
the values registered with IANA. registered with IANA.
o Block Length (16 bits): The length of this report block, o Block Length (16 bits): The length of this report block,
including the header, in 32-bit words minus one. including the header, in 32-bit words minus one.
o SSRC of the Primary Multicast Stream (32 bits): Mandatory field o SSRC of the Primary Multicast Stream (32 bits): Field that
that denotes the SSRC of the primary multicast stream. denotes the SSRC of the primary multicast stream.
o Status (16 bits): Mandatory field that denotes the status code o Status (16 bits): Field that denotes the status code for the MA
for the MA operation. operation.
This document defines several status codes and registers them with This document defines several status codes and registers them with
IANA in Section 7.5. If a new vendor-neutral status code will be IANA in Section 7.5. If a new vendor-neutral status code will be
defined, it MUST be registered with IANA through the guidelines defined, it MUST be registered with IANA through the guidelines
specified in Section 7.5. If the new status code is intended to 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 be used privately by a vendor, there is no need for IANA
management. Section 4.2.2 defines how a vendor defines and uses management. Section 4.2.2 defines how a vendor defines and uses
private extensions to convey its messages. To indicate a private private extensions to convey its messages.
extension, the RTP receiver MUST set the Status field to zero.
o Rsvd. (16 bits): The RTP receiver MUST set this bit to zero. The To indicate use of a private extension, the RTP receiver MUST set
recipient MUST ignore this bit when received. the Status field to zero. A private extension MUST NOT be used in
an XR report unless the RTP receiver knows from out-of-band
methods that the entity that will receive and process the XR
report 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.
If the multicast join was successful meaning that at least one If the multicast join was successful meaning that at least one
multicast packet has been received, some additional information MUST multicast packet has been received, some additional information MUST
be appended to the base report as will be described in Section 4.2.1. be appended to the base report as will be described in Section 4.2.1.
4.1.1. Status Code Rules for New MA Methods 4.1.1. Status Code Rules for New MA Methods
Different MA methods usually use different status codes, although Different MA methods usually use different status codes, although
some status codes (e.g., a code indicating that multicast join has some status codes (e.g., a code indicating that multicast join has
failed) can be common among multiple MA methods. The status code failed) can be common among multiple MA methods. The status code
skipping to change at page 9, line 44 skipping to change at page 10, line 7
o SFGMP Join Time (32 bits): TLV element that denotes the greater o SFGMP Join Time (32 bits): TLV element that denotes the greater
of zero or the time difference (in ms) between the instant SFGMP of zero or the time difference (in ms) between the instant SFGMP
Join message has been sent and the instant the first packet was Join message has been sent and the instant the first packet was
received in the multicast session. If the multicast join was received in the multicast session. If the multicast join was
successful, this element MUST be included. If no multicast packet successful, this element MUST be included. If no multicast packet
has been received, this element MUST NOT exist in the report has been received, this element MUST NOT exist in the report
block. block.
Type: 2 Type: 2
o Application Request-to-Multicast Delta Time (32 bits): Optional o Application Request-to-Multicast Delta Time (32 bits): OPTIONAL
TLV element that denotes the time difference (in ms) between the TLV element that denotes the time difference (in ms) between the
instant the application became aware it would join a new multicast instant the application became aware it would join a new multicast
session and the instant the first RTP packet was received from the session and the instant the first RTP packet was received from the
primary multicast stream. If no such packet has been received, primary multicast stream. If no such packet has been received,
this element MUST NOT exist in the report block. this element MUST NOT exist in the report block.
Type: 3 Type: 3
o Application Request-to-Presentation Delta Time (32 bits): o Application Request-to-Presentation Delta Time (32 bits):
Optional TLV element that denotes the time difference (in ms) OPTIONAL TLV element that denotes the time difference (in ms)
between the instant the application became aware it would join a between the instant the application became aware it would join a
new multicast session and the instant the media is first new multicast session and the instant the media is first
presented. If the RTP receiver cannot successfully present the presented. If the RTP receiver cannot successfully present the
media, this element MUST NOT exist in the report block. media, this element MUST NOT exist in the report block.
Type: 4 Type: 4
We next present the TLV elements that can be used when the RTP We next present the TLV elements that can be used when the RTP
receiver supports and uses the RAMS method described in receiver supports and uses the RAMS method described in
[I-D.ietf-avt-rapid-acquisition-for-rtp]. However, if the RTP [I-D.ietf-avt-rapid-acquisition-for-rtp]. However, if the RTP
receiver does not send a rapid acquisition request, the following TLV receiver does not send a rapid acquisition request, the following TLV
elements MUST NOT exist in the MA report block. Some elements may or elements MUST NOT exist in the MA report block. Some elements may or
may not exist depending on whether the RTP receiver receives any may not exist depending on whether the RTP receiver receives any
packet from the unicast burst and/or the primary multicast stream or packet from the unicast burst and/or the primary multicast stream or
not. These are explained below. not. These are explained below.
o Application Request-to-RAMS Request Delta Time (32 bits): o Application Request-to-RAMS Request Delta Time (32 bits):
Optional TLV element that denotes the time difference (in ms) OPTIONAL TLV element that denotes the time difference (in ms)
between the instant the application became aware it would request between the instant the application became aware it would request
a rapid acquisition and the instant the rapid acquisition request a rapid acquisition and the instant the rapid acquisition request
was actually sent by the application. was actually sent by the application.
Type: 11 Type: 11
o RAMS Request-to-RAMS Information Delta Time (32 bits): Optional o RAMS Request-to-RAMS Information Delta Time (32 bits): OPTIONAL
TLV element that denotes the time difference (in ms) between the TLV element that denotes the time difference (in ms) between the
instant the rapid acquisition request has been sent and the instant the rapid acquisition request has been sent and the
instant the first RAMS Information message was received in the instant the first RAMS Information message was received in the
unicast session. If no such message has been received, this unicast session. If no such message has been received, this
element MUST NOT exist in the report block. element MUST NOT exist in the report block.
Type: 12 Type: 12
o RAMS Request-to-Burst Delta Time (32 bits): Optional TLV element o RAMS Request-to-Burst Delta Time (32 bits): OPTIONAL TLV element
that denotes the time difference (in ms) between the instant the that denotes the time difference (in ms) between the instant the
rapid acquisition request has been sent and the instant the first rapid acquisition request has been sent and the instant the first
burst packet was received in the unicast session. If no burst burst packet was received in the unicast session. If no burst
packet has been received, this element MUST NOT exist in the packet has been received, this element MUST NOT exist in the
report block. report block.
Type: 13 Type: 13
o RAMS Request-to-Multicast Delta Time (32 bits): Optional TLV o RAMS Request-to-Multicast Delta Time (32 bits): OPTIONAL TLV
element that denotes the time difference (in ms) between the element that denotes the time difference (in ms) between the
instant the rapid acquisition request has been sent and the instant the rapid acquisition request has been sent and the
instant the first RTP packet was received from the primary instant the first RTP packet was received from the primary
multicast stream. If no such packet has been received, this multicast stream. If no such packet has been received, this
element MUST NOT exist in the report block. element MUST NOT exist in the report block.
Type: 14 Type: 14
o RAMS Request-to-Burst-Completion Delta Time (32 bits): Optional o RAMS Request-to-Burst-Completion Delta Time (32 bits): OPTIONAL
TLV element that denotes the time difference (in ms) between the TLV element that denotes the time difference (in ms) between the
instant the rapid acquisition request has been sent and the instant the rapid acquisition request has been sent and the
instant the last burst packet was received in the unicast session. instant the last burst packet was received in the unicast session.
If no burst packet has been received, this element MUST NOT exist If no burst packet has been received, this element MUST NOT exist
in the report block. in the report block.
Type: 15 Type: 15
o Number of Duplicate Packets (32 bits): Optional TLV element that o Number of Duplicate Packets (32 bits): OPTIONAL TLV element that
denotes the number of duplicate packets due to receiving the same denotes the number of duplicate packets due to receiving the same
packet in both unicast and primary multicast RTP sessions. If no packet in both unicast and primary multicast RTP sessions. If no
RTP packet has been received from the primary multicast stream, RTP packet has been received from the primary multicast stream,
this element MUST NOT exist. If no burst packet has been received 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 in the unicast session, the value of this element MUST be set to
zero. zero.
Type: 16 Type: 16
o Size of Burst-to-Multicast Gap (32 bits): Optional TLV element o Size of Burst-to-Multicast Gap (32 bits): OPTIONAL TLV element
that denotes the greater of zero or the difference between the that denotes the greater of zero or the difference between the
sequence number of the first multicast packet (received from the sequence number of the first multicast packet (received from the
primary multicast stream) and the sequence number of the last primary multicast stream) and the sequence number of the last
burst packet minus 1 (considering the wrapping of the sequence burst packet minus 1 (considering the wrapping of the sequence
numbers). If no burst packet has been received in the unicast numbers). If no burst packet has been received in the unicast
session or no RTP packet has been received from the primary session or no RTP packet has been received from the primary
multicast stream, this element MUST NOT exist in the report block. multicast stream, this element MUST NOT exist in the report block.
Type: 17 Type: 17
skipping to change at page 16, line 21 skipping to change at page 16, line 21
This document creates a new IANA TLV space registry for the MA report This document creates a new IANA TLV space registry for the MA report
block extensions. The registry is called the Multicast Acquisition block extensions. The registry is called the Multicast Acquisition
Report Block TLV Space Registry. This registry is to be managed by Report Block TLV Space Registry. This registry is to be managed by
the IANA according to the Specification Required policy of [RFC5226]. the IANA according to the Specification Required policy of [RFC5226].
The length of the Type field in the TLV elements is a single octet, The length of the Type field in the TLV elements is a single octet,
allowing 256 values. The registry is initialized with the following allowing 256 values. The registry is initialized with the following
entries: entries:
Type Description Reference Type Description Reference
---- -------------------------------------------------- ------------- ------- -------------------------------------------------- ---------
1 RTP Seqnum of the First Multicast Packet [RFCXXXX] 0 Reserved [RFCXXXX]
2 SFGMP Join Time [RFCXXXX] 1 RTP Seqnum of the First Multicast Packet [RFCXXXX]
3 Application Request-to-Multicast Delta Time [RFCXXXX] 2 SFGMP Join Time [RFCXXXX]
4 Application Request-to-Presentation Delta Time [RFCXXXX] 3 Application Request-to-Multicast Delta Time [RFCXXXX]
11 Application Request-to-RAMS Request Delta Time [RFCXXXX] 4 Application Request-to-Presentation Delta Time [RFCXXXX]
12 RAMS Request-to-RAMS Information Delta Time [RFCXXXX] 11 Application Request-to-RAMS Request Delta Time [RFCXXXX]
13 RAMS Request-to-Burst Delta Time [RFCXXXX] 12 RAMS Request-to-RAMS Information Delta Time [RFCXXXX]
14 RAMS Request-to-Multicast Delta Time [RFCXXXX] 13 RAMS Request-to-Burst Delta Time [RFCXXXX]
15 RAMS Request-to-Burst-Completion Delta Time [RFCXXXX] 14 RAMS Request-to-Multicast Delta Time [RFCXXXX]
16 Number of Duplicate Packets [RFCXXXX] 15 RAMS Request-to-Burst-Completion Delta Time [RFCXXXX]
17 Size of Burst-to-Multicast Gap [RFCXXXX] 16 Number of Duplicate Packets [RFCXXXX]
17 Size of Burst-to-Multicast Gap [RFCXXXX]
18-127 Specification Required
128-254 Reserved for private extensions [RFCXXXX]
255 Reserved [RFCXXXX]
The Type values 0 and 255 are reserved for future use. The Type The Type values 0 and 255 are reserved for future use. The Type
values between (and including) 128 and 254 are reserved for private values between (and including) 128 and 254 are reserved for private
extensions. extensions.
Any registration for an unassigned Type value needs to contain the Any registration for an unassigned Type value needs to contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
skipping to change at page 17, line 19 skipping to change at page 17, line 19
Space Registry. This registry is to be managed by the IANA according Space Registry. This registry is to be managed by the IANA according
to the Specification Required policy of [RFC5226]. to the Specification Required policy of [RFC5226].
The length of the Status field is two octets, allowing 65536 codes. The length of the Status field is two octets, allowing 65536 codes.
However, the status codes have been registered to allow for an easier However, the status codes have been registered to allow for an easier
classification. For example, the values between (and including) 1 classification. For example, the values between (and including) 1
and 1000 are primarily used by the MA method of simple join. The 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 values between (and including) 1001 and 2000 are used by the MA
method described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. When method described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. When
registering new status codes for the existing MA methods or newly registering new status codes for the existing MA methods or newly
defined MA methods, a similar classification scheme is encouraged to defined MA methods, registrants are encouraged to allocate sufficient
be followed. 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 The Status code 65535 is reserved for future use. The registry is
initialized with the following entries: initialized with the following entries:
Code Description Reference Code Description Reference
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- -------------
0 A private status code is included in the message [RFCXXXX] 0 A private status code is included in the message [RFCXXXX]
1 Multicast join was successful [RFCXXXX] 1 Multicast join was successful [RFCXXXX]
2 Multicast join has failed [RFCXXXX] 2 Multicast join has failed [RFCXXXX]
skipping to change at page 17, line 42 skipping to change at page 17, line 43
4 An unspecified RR internal error has occurred [RFCXXXX] 4 An unspecified RR internal error has occurred [RFCXXXX]
1001 RAMS has been successfully completed [RFCXXXX] 1001 RAMS has been successfully completed [RFCXXXX]
1002 No RAMS-R message has been sent [RFCXXXX] 1002 No RAMS-R message has been sent [RFCXXXX]
1003 Invalid RAMS-I message syntax [RFCXXXX] 1003 Invalid RAMS-I message syntax [RFCXXXX]
1004 RAMS-I message has timed out [RFCXXXX] 1004 RAMS-I message has timed out [RFCXXXX]
1005 RAMS unicast burst has timed out [RFCXXXX] 1005 RAMS unicast burst has timed out [RFCXXXX]
1006 An unspecified RR internal error has occurred 1006 An unspecified RR internal error has occurred
during RAMS [RFCXXXX] during RAMS [RFCXXXX]
1007 A presentation error has occurred during RAMS [RFCXXXX] 1007 A presentation error has occurred during RAMS [RFCXXXX]
65535 Reserved [RFCXXXX]
Any registration for an unassigned Status code needs to contain the Any registration for an unassigned Status code needs to contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new Status code describes and o A detailed description of what the new Status code describes and
how it is interpreted. how it is interpreted.
 End of changes. 29 change blocks. 
89 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/