draft-ietf-avtext-multicast-acq-rtcp-xr-00.txt   draft-ietf-avtext-multicast-acq-rtcp-xr-01.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: September 6, 2011 March 5, 2011 Expires: October 1, 2011 March 30, 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-00 draft-ietf-avtext-multicast-acq-rtcp-xr-01
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. One approach to reduce this delay is to receive a acquisition delay. An RTP receiver may use one ore more different
burst stream from a retransmission server that facilitates rapid approaches to achieve rapid acquisition. Yet, due to various
acquisition of the multicast stream. An RTP receiver may use this factors, performance of the rapid acquisition methods usually varies.
approach (or any other approach) to achieve rapid acquisition. Yet, Furthermore, in some cases the RTP receiver may (or may have to) do a
due to various factors, performance of the rapid acquisition methods simple multicast join. For quality reporting, monitoring and
usually varies. Furthermore, in some cases the RTP receiver may (or diagnostics purposes, it is important to collect detailed information
may have to) do a simple multicast join. For quality reporting, from the RTP receivers about their acquisition and presentation
monitoring and diagnostics purposes, it is important to collect experiences. This document addresses this issue by defining a new
detailed information from the RTP receivers about their acquisition report block type, called Multicast Acquisition (MA) Report Block,
and presentation experiences. This document addresses this issue by within the framework of RTP Control Protocol (RTCP) Extended Reports
defining a new report block type, called Multicast Acquisition (MA) (XR) (RFC 3611). This document also defines the necessary signaling
Report Block, within the framework of RTP Control Protocol (RTCP) of the new MA report block type in the Session Description Protocol
Extended Reports (XR) (RFC 3611). This document also defines the (SDP).
necessary signaling of the new MA report block type in the Session
Description Protocol (SDP).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 6, 2011. This Internet-Draft will expire on October 1, 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 29 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . 7 4.1.1. Status Code Rules . . . . . . . . . . . . . . . . . . 7
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 8 4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 9
4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 11 4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 11
5. Session Description Protocol Signaling . . . . . . . . . . . . 12 5. Session Description Protocol Signaling . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 14 7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 15
7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 14 7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 15
7.3. Multicast Acquisition Method Registry . . . . . . . . . . 14 7.3. Multicast Acquisition Method Registry . . . . . . . . . . 15
7.4. Multicast Acquisition Report Block TLV Space Registry . . 15 7.4. Multicast Acquisition Report Block TLV Space Registry . . 16
7.5. Multicast Acquisition Status Code Space Registry . . . . . 16 7.5. Multicast Acquisition Status Code Space Registry . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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 6, line 24 skipping to change at page 6, line 24
[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 MAY define their own extensions to be used in the rapid acquisition MAY 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).
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 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 |
skipping to change at page 7, line 9 skipping to change at page 7, line 22
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): Mandatory field
that denotes the SSRC of the primary multicast stream. that denotes the SSRC of the primary multicast stream.
o Status (16 bits): Mandatory field that denotes the status code o Status (16 bits): Mandatory field that denotes the status code
for the MA operation. for the MA operation.
This document defines several status codes and registers them with This document defines several status codes and registers them with
IANA. If a new vendor-neutral status code will be defined, it IANA in Section 7.5. If a new vendor-neutral status code will be
MUST be registered with IANA through the guidelines specified in defined, it MUST be registered with IANA through the guidelines
Section 7.5. If the new status code is intended to be used specified in Section 7.5. If the new status code is intended to
privately by a vendor, there is no need for IANA management. be used privately by a vendor, there is no need for IANA
Instead, the vendor MUST use the private extension mechanism management. Instead, the vendor MUST use the private extension
(Section 4.2.2) to convey its message and MUST indicate this by mechanism (Section 4.2.2) to convey its message and MUST indicate
putting zero in the Status field. this by putting zero in the Status field.
o Rsvd. (16 bits): This field SHALL be set to 0 and ignored. 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 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 4.1.1. Status Code Rules
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) may apply to more than one MA method. However, the status failed) may apply to more than one MA method. However, the status
skipping to change at page 8, line 11 skipping to change at page 8, line 25
the response code as its status code. In other words, the 4xx and 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 5xx-level response codes have a higher priority than the 1xxx-level
status codes. The 5xx-level response codes have a higher priority status codes. The 5xx-level response codes have a higher priority
than the 4xx-level response codes and MUST be reported in the base 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 report in case the RTP receiver receives both 4xx and 5xx-level
response codes (in different RAMS-I messages) during the same RAMS response codes (in different RAMS-I messages) during the same RAMS
session. session.
4.2. Extensions 4.2. Extensions
To improve the reporting scope, it may be desirable to define new 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 fields in the MA report block. Such fields MUST be encoded as TLV
elements as described below and sketched in Figure 2: elements as described below and sketched in Figure 2:
o Type: A single-octet identifier that defines the type of the o Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element. parameter represented in this TLV element.
o Length: A two-octet field that indicates the length (in octets) o Length: A two-octet field that indicates the length (in octets)
of the TLV element excluding the Type and Length fields, and the of the TLV element excluding the Type and Length fields, and the
8-bit Reserved field between them. Note that this length does not 8-bit Reserved field between them. Note that this length does not
include any padding that is required for alignment. include any padding that is required for alignment.
o Value: Variable-size set of octets that contains the specific o Value: Variable-size set of octets that contains the specific
value for the parameter. value for the parameter.
In the extensions, the Reserved field SHALL be set to zero and In the extensions, the Reserved field SHALL be set to zero and
ignored. If a TLV element does not fall on a 32-bit boundary, the ignored on reception. If a TLV element does not fall on a 32-bit
last word MUST be padded to the boundary using further bits set to boundary, the last word MUST be padded to the boundary using further
zero. bits set to zero.
In the MA report block, any vendor-neutral or private extension MUST In the MA report block, any vendor-neutral or private extension MUST
be placed after the base report. be placed after the base report.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value : : Value :
skipping to change at page 11, line 26 skipping to change at page 11, line 43
multicast stream, this element SHALL NOT exist. multicast stream, this element SHALL NOT exist.
Type: 17 Type: 17
4.2.2. Private Extensions 4.2.2. Private Extensions
It is desirable to allow vendors to use private extensions in TLV It is desirable to allow vendors to use private extensions in TLV
format. For interoperability, such extensions MUST NOT collide with format. For interoperability, such extensions MUST NOT collide with
each other. each other.
A certain range of TLV Types is reserved for private extensions The range of [128-254] of TLV Types is reserved for private
(Refer to Section 7.4). IANA management for these extensions is extensions. IANA management for these extensions is unnecessary and
unnecessary and they are the responsibility of individual vendors. they are the responsibility of individual vendors.
The structure that MUST be used for the private extensions is The structure that MUST be used for the private extensions is
depicted in Figure 3. Here, the enterprise numbers are used from depicted in Figure 3. Here, the private enterprise numbers are used
http://www.iana.org/assignments/enterprise-numbers. This will ensure from http://www.iana.org/assignments/enterprise-numbers. This will
the uniqueness of the private extensions and avoid any collision. ensure the uniqueness of the private extensions and avoid any
collision.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number | | Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value : : Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Structure of a private extension Figure 3: Structure of a private extension
5. Session Description Protocol Signaling 5. Session Description Protocol Signaling
A new parameter is defined for the MA report block to be used with A new unilateral parameter is defined for the MA report block to be
the Session Description Protocol (SDP) [RFC4566] using the Augmented used with the Session Description Protocol (SDP) [RFC4566] using the
Backus-Naur Form (ABNF) [RFC5234]. It has the following syntax Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the following
within the 'rtcp-xr' attribute [RFC3611]: syntax within the 'rtcp-xr' attribute [RFC3611]:
multicast-acq-ext = "multicast-acq" multicast-acq-ext = "multicast-acq"
Figure 4 Figure 4
Refer to Section 5.1 of [RFC3611] for a detailed description and the Refer to Section 5.1 of [RFC3611] for a detailed description and the
full syntax of the "rtcp-xr" attribute. The "multicast-acq-ext" full syntax of the "rtcp-xr" attribute. The "multicast-acq-ext"
parameter is compatible with the definition of "format-ext" in the parameter is compatible with the definition of "format-ext" in the
"rtcp-xr" attribute. "rtcp-xr" attribute.
6. Security Considerations 6. Security Considerations
The security considerations of [RFC3611] apply in this document as The security considerations of [RFC3611] apply in this document as
well. If desired, similar to other RTCP XR reports, the MA reports well.
MAY be protected by using Secure RTP (SRTP) and Secure RTP Control
Protocol (SRTCP) [RFC3711]. 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 Using the MA reports to provide feedback into the acquisition of the
multicast streams can introduce possible additional security multicast streams can introduce possible additional security
implications. If a forged or otherwise modified MA report is implications. If a forged or otherwise modified MA report is
received for an earlier acquisition attempt, invalid data may be used received for an earlier acquisition attempt, invalid data may be used
as input in later rapid acquisition attempts. For example, as input in later rapid acquisition attempts. For example,
incorrectly small SFGMP join times may cause the unicast burst to be incorrectly small SFGMP join times could cause the unicast burst to
too short, leading to gaps in sequence numbers in the approach be too short, leading to gaps in sequence numbers in the approach
discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally, discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally,
forged reports may give the appearance that rapid acquisition is forged reports could give the appearance that rapid acquisition is
performing correctly, when it is in fact failing, or vice versa. 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.
7. IANA Considerations 7. IANA Considerations
The following contact information shall be used for all registrations The following contact information shall be used for all registrations
in this document: in this document:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
Note to the RFC Editor: In the following, please replace "XXXX" with Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC. the number of this document prior to publication as an RFC.
7.1. RTCP XR Block Type 7.1. RTCP XR Block Type
New block types for RTCP XR are subject to IANA registration. For Type value 11 has been pre-registered with IANA for the "Multicast
general guidelines on IANA considerations for RTCP XR, refer to Acquisition Report Block" in the RTCP XR Block Type Registry.
[RFC3611].
This document assigns the block type value 11 in the RTCP XR Block
Type Registry to "Multicast Acquisition Report Block."
7.2. RTCP XR SDP Parameter 7.2. RTCP XR SDP Parameter
This document registers the SDP [RFC4566] parameter 'multicast-acq' This document registers the SDP [RFC4566] parameter 'multicast-acq'
for the 'rtcp-xr' attribute in the RTCP XR SDP Parameters Registry. for the 'rtcp-xr' attribute in the RTCP XR SDP Parameters Registry.
7.3. Multicast Acquisition Method Registry 7.3. Multicast Acquisition Method Registry
This document creates a new IANA registry for the MA methods. The This document creates a new IANA registry for the MA methods. The
registry is called the Multicast Acquisition Method Registry. This registry is called the Multicast Acquisition Method Registry. This
skipping to change at page 14, line 50 skipping to change at page 15, line 46
MA Method Description Reference MA Method Description Reference
--------- ------------------------------------ ------------- --------- ------------------------------------ -------------
0 Reserved [RFCXXXX] 0 Reserved [RFCXXXX]
1 Simple join (No explicit method) [RFCXXXX] 1 Simple join (No explicit method) [RFCXXXX]
2 RAMS [I-D.ietf-avt-rapid-acquisition-for-rtp] 2 RAMS [I-D.ietf-avt-rapid-acquisition-for-rtp]
3-254 Specification Required 3-254 Specification Required
255 Reserved [RFCXXXX] 255 Reserved [RFCXXXX]
The MA Method values 0 and 255 are reserved for future use. The MA Method values 0 and 255 are reserved for future use.
Any registration for an unassigned value MUST contain the following Any registration for an unassigned value needs to contain the
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 how the MA method works. o A detailed description of how the MA method works.
7.4. Multicast Acquisition Report Block TLV Space Registry 7.4. Multicast Acquisition Report Block TLV Space Registry
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
skipping to change at page 15, line 40 skipping to change at page 16, line 39
13 RAMS Request-to-Burst Delta Time [RFCXXXX] 13 RAMS Request-to-Burst Delta Time [RFCXXXX]
14 RAMS Request-to-Multicast Delta Time [RFCXXXX] 14 RAMS Request-to-Multicast Delta Time [RFCXXXX]
15 RAMS Request-to-Burst-Completion Delta Time [RFCXXXX] 15 RAMS Request-to-Burst-Completion Delta Time [RFCXXXX]
16 Number of Duplicate Packets [RFCXXXX] 16 Number of Duplicate Packets [RFCXXXX]
17 Size of Burst-to-Multicast Gap [RFCXXXX] 17 Size of Burst-to-Multicast Gap [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 MUST 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.
o A detailed description of what the new TLV element represents and o A detailed description of what the new TLV element represents and
how it shall be interpreted. how it shall be interpreted.
7.5. Multicast Acquisition Status Code Space Registry 7.5. Multicast Acquisition Status Code Space Registry
skipping to change at page 16, 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 SHOULD be defined MA methods, a similar classification scheme is encouraged to
followed. be followed.
The Status code 65536 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]
3 A presentation error has occurred [RFCXXXX] 3 A presentation error has occurred [RFCXXXX]
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]
Any registration for an unassigned Status code MUST 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 shall be interpreted. how it shall be interpreted.
8. Acknowledgments 8. Acknowledgments
 End of changes. 25 change blocks. 
74 lines changed or deleted 88 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/