[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item
Fellow AVT folks-
We are continuing to solicit comments on the RAMS design points
identified in Ali's email from May 15 (diff enclosed). We have received
some valuable feedback. We hope to have a new draft mid next week, and
will incorporate comments that we receive through Monday or Tuesday in
that draft.
Thanks in advance
Bill VerSteeg
-----Original Message-----
From: Ali C. Begen (abegen)
Sent: Friday, May 15, 2009 1:32 PM
To: Roni Even; Bill Ver Steeg (versteb); avt at ietf.org
Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP
Sessions(RAMS) as a working group item
Hi Roni, All,
Here is a diff for sections 7 and 13.
Comments are welcome.
-acbegen
Section 7., paragraph 1:
OLD:
This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between the Retransmission Server (RS)
and RTP Receiver (RR) during rapid acquisition. These messages are
payload-independent and MUST be used by all RTP-based multicast
applications that support rapid acquisition regardless of the payload
they carry.
NEW:
This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between the Retransmission Server (RS)
and RTP Receiver (RR) during rapid acquisition. These messages are
referred to as the RAMS Messages. They are payload-independent and
MUST be used by all RTP-based multicast applications that support
rapid acquisition regardless of the payload they carry.
Section 7., paragraph 2:
OLD:
Specific payload formats are not defined in this document, but a
framework is presented that allows payload-specific information to be
included in the exchange.
NEW:
Payload-specific feedback messages are not defined in this document,
but an extension mechanism is provided where further optional
payload-independent and payload-specific information can be included
in the exchange.
Section 7., paragraph 3:
OLD:
The common packet format for the RTCP feedback messages is defined in
Section 6.1 of [RFC4585]. Each feedback message has a fixed-length
field for version, padding, feedback message type (FMT), payload type
(PT), length, SSRC of packet sender, SSRC of media source as well as
a variable-length field for feedback control information (FCI). In
the transport-layer feedback messages, the PT field is set to RTPFB
(205).
NEW:
The common packet format for the RTCP feedback messages is defined in
Section 6.1 of [RFC4585]. Each feedback message has a fixed-length
field for version, padding, feedback message type (FMT), payload type
(PT), length, SSRC of packet sender, SSRC of media source as well as
a variable-length field for feedback control information (FCI).
Section 7., paragraph 4:
OLD:
In the feedback messages defined in this section, optional extensions
are encoded by using TLV elements as described below and sketched in
Figure 4:
NEW:
In the RAMS messages, the PT field is set to RTPFB (205) and the FMT
field is set to RAMS (6). Individual RAMS messages are identified by
a sub-field called Sub Feedback Message Type (SFMT).
7.1. Extensions
To improve the functionality of the RAMS method in certain
applications, it may be desirable to define new fields in the RAMS
Request, Information and Termination messages. Such fields MUST be
encoded as TLV elements as described below and sketched in Figure 4:
Section 7., paragraph 6:
OLD:
o Length: A two-octet field that indicates the length of the Value
field in octets.
NEW:
o Length: A two-octet field that indicates the length of the TLV
element excluding the Type and Length fields in octets. Note that
this length does not include any padding that is required for
alignment.
Section 7., paragraph 9:
OLD:
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 | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW:
In an RAMS message any vendor-neutral or private extension MUST be
placed after the mandatory fields (if any). The support for
extensions is OPTIONAL.
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 | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 7., paragraph 10:
OLD:
Figure 4: Structure of a TLV element
Editor's note: The optional fields in the RAMS messages (defined
below) will be converted to TLV elements in a later version of this
document.
NEW:
Figure 4: Structure of a TLV element
Section 7., paragraph 11:
OLD:
7.1. RAMS Request
NEW:
7.1.1. Vendor-Neutral Extensions
Section 7., paragraph 12:
OLD:
The RAMS Request message is identified by PT=RTPFB and FMT=6.
NEW:
If the goal in defining new TLV elements is to extend the
functionality in a vendor-neutral manner, they MUST be registered
with IANA through the guidelines provided in Section 13.4.
The current document defines several vendor-neutral extensions in the
following sections.
7.1.2. Private Extensions
It is desirable to allow vendors to use private extensions in TLV
format. For interoperability, such extensions MUST NOT collide with
each other.
A certain range of TLV Types is reserved for private extensions
(Refer to Section 13.4). IANA management for these extensions is
unnecessary and they are the responsibility of individual vendors.
The structure that MUST be used for the private extensions is
depicted in Figure 5. Here, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure
the uniqueness of the private extensions and avoid any collision.
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 | Length | Ent. Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. Number contd. | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of a private extension
7.2. RAMS Request
The RAMS Request message is identified by SFMT=1.
Section 7., paragraph 15:
OLD:
The FCI field has the structure depicted in Figure 5.
NEW:
The FCI field has the structure depicted in Figure 6.
Section 7., paragraph 17:
OLD:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min RAMS Buffer Fill Requirement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max RAMS Buffer Fill Requirement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Receive Bitrate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (TLV-encoded Extensions) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=1 | Optional TLV-encoded Fields |
+-+-+-+-+-+-+-+-+ |
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 7., paragraph 18:
OLD:
Figure 5: FCI field syntax for the RAMS Request message
NEW:
Figure 6: FCI field syntax for the RAMS Request message
Section 7., paragraph 22:
OLD:
o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the maximum number of octets of content the RTP
receiver can buffer without losing the burst data due to buffer
overflow.
NEW:
Type: TBD
Length: TBD
o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the maximum number of octets of content the RTP
receiver can buffer without losing the burst data due to buffer
overflow.
Section 7., paragraph 25:
OLD:
o Max Receive Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that the RTP receiver can
process the unicast burst. This rate should include whatever
knowledge the receiver has that would provide an upper bound on
the unicast burst bitrate. The limits may include local receiver
limits as well as network limits that are known to the receiver.
NEW:
Type: TBD
Length: TBD
o Max Receive Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that the RTP receiver can
process the unicast burst. This rate should include whatever
knowledge the receiver has that would provide an upper bound on
the unicast burst bitrate. The limits may include local receiver
limits as well as network limits that are known to the receiver.
Section 7., paragraph 27:
OLD:
The semantics of the RAMS-R feedback message is independent of the
payload type.
NEW:
Type: TBD
Length: TBD
The semantics of the RAMS-R feedback message is independent of the
payload type.
Section 7., paragraph 28:
OLD:
7.2. RAMS Information
NEW:
7.3. RAMS Information
Section 7., paragraph 29:
OLD:
The RAMS Information message is identified by PT=RTPFB and FMT=7.
NEW:
The RAMS Information message is identified by SFMT=2.
Section 7., paragraph 32:
OLD:
The FCI field has the structure depicted in Figure 6.
NEW:
The FCI field has the structure depicted in Figure 7.
Section 7., paragraph 33:
OLD:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSN |S| Response | Rsvd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended RTP Seqnum of the First Burst Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest Multicast Join Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Burst Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Burst Bitrate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (TLV-encoded Extensions) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=2 | MSN |S| Response | Rsvd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended RTP Seqnum of the First Burst Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 7., paragraph 34:
OLD:
Figure 6: FCI field syntax for the RAMS Information message
NEW:
Figure 7: FCI field syntax for the RAMS Information message
Section 7., paragraph 41:
OLD:
1. Success
2. Bad_Request
NEW:
1. Success
2. Bad_Request
Section 7., paragraph 45:
OLD:
o Rsvd (16 bits): Reserved. This field SHALL be set to 0.
NEW:
o Rsvd (8 bits): Reserved. This field SHALL be set to 0.
Section 7., paragraph 50:
OLD:
o Burst Duration (32 bits): Optional TLV element that denotes the
duration of the burst that RS is planning to send (in RTP ticks).
In the absence of additional stimulus, RS will send a burst of
this duration. However, the burst duration may be modified by
subsequent events, including changes in the primary multicast
stream and reception of RAMS-T messages.
NEW:
Type: TBD
Length: TBD
o Burst Duration (32 bits): Optional TLV element that denotes the
duration of the burst that RS is planning to send (in RTP ticks).
In the absence of additional stimulus, RS will send a burst of
this duration. However, the burst duration may be modified by
subsequent events, including changes in the primary multicast
stream and reception of RAMS-T messages.
Section 7., paragraph 52:
OLD:
o Max Burst Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that will be used by RS
for the unicast burst.
NEW:
Type: TBD
Length: TBD
o Max Burst Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that will be used by RS
for the unicast burst.
Section 7., paragraph 53:
OLD:
The semantics of the RAMS-I feedback message is independent of the
payload type.
NEW:
Type: TBD
Length: TBD
The semantics of the RAMS-I feedback message is independent of the
payload type.
Section 7., paragraph 55:
OLD:
7.3. RAMS Termination
NEW:
7.4. RAMS Termination
Section 7., paragraph 56:
OLD:
The RAMS Termination message is identified by PT=RTPFB and FMT=8.
NEW:
The RAMS Termination message is identified by SFMT=3.
Section 7., paragraph 61:
OLD:
The FCI field has the structure depicted in Figure 7.
NEW:
The FCI field has the structure depicted in Figure 8.
Section 7., paragraph 62:
OLD:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended RTP Seqnum of First Multicast Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (TLV-encoded Extensions) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=3 | Optional TLV-encoded Fields |
+-+-+-+-+-+-+-+-+ |
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 7., paragraph 63:
OLD:
Figure 7: FCI field syntax for the RAMS Termination message
NEW:
Figure 8: FCI field syntax for the RAMS Termination message
Section 7., paragraph 65:
OLD:
The semantics of the RAMS-T feedback message is independent of the
payload type.
7.4. Extensions
To improve the functionality of the RAMS method in certain
applications, it may be desirable to define new fields in the RAMS
Request, Information and Termination messages. Such fields MUST be
defined as TLV elements. If the goal in defining these new fields is
to extend the protocol in a vendor-neutral manner, they MUST be
registered with IANA through an Informational or a Standards-track
RFC. The support for these new fields is OPTIONAL. In an RAMS
message, any extension MUST be placed after any existing mandatory
field for that message.
Editor's note: We should specify the requirements for registering
new TLV elements.
It is also desirable to allow vendors to use vendor-specific
extensions (in TLV format) in any of the RAMS messages. For
interoperability, such extensions MUST NOT collide with each other.
Editor's note: Some approaches are currently being examined for
vendor-specific extensions. A potential solution is depicted in
Figure 8. In this approach, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure
the uniqueness of the vendor-specific extensions.
NEW:
Type: TBD
Section 7., paragraph 66:
OLD:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Mandatory Fields as Defined in This Document :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | Ent. Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. Number contd. | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW:
Length: TBD
Section 7., paragraph 67:
OLD:
Figure 8: Structure of a vendor-specific extension
NEW:
The semantics of the RAMS-T feedback message is independent of the
payload type.
Section 13., paragraph 1:
OLD:
This document registers a new SDP attribute value and several new
RTCP packets.
The following contact information shall be used for all registrations
in this document:
NEW:
The following contact information shall be used for all registrations
in this document:
Section 13.2., paragraph 1:
OLD:
Within the RTPFB range, the following three format (FMT) values are
registered:
NEW:
Within the RTPFB range, the following format (FMT) value is
registered:
Section 13.2., paragraph 2:
OLD:
Name: RAMS-R
Long name: Rapid Acquisition of Multicast Sessions Request
Value: 6
Reference: This document
NEW:
Name: RAMS
Long name: Rapid Acquisition of Multicast Sessions
Value: 6
Reference: This document
Section 13.2., paragraph 3:
OLD:
Name: RAMS-I
Long name: Rapid Acquisition of Multicast Sessions Information
Value: 7
Reference: This document
NEW:
13.3. SFMT Values for RAMS Messages Registry
Section 13.2., paragraph 4:
OLD:
Name: RAMS-T
Long name: Rapid Acquisition of Multicast Sessions Termination
Value: 8
Reference: This document
NEW:
This document creates a new sub-registry for the sub-feedback message
type (SFMT) values to be used with the FMT value registered for RAMS
messages. The registry is called the SFMT Values for RAMS Messages
Registry. This registry is to be managed by the IANA according to
the Specification Required policy of [RFC5226].
The length of the SFMT field in the RAMS messages is a single octet,
allowing 256 values. The registry is initialized with the following
entries:
Value Name Reference
----- -------------------------------------------------- -------------
1 RAMS Request This document
2 RAMS Information This document
3 RAMS Termination This document
The SFMT values 0 and 255 are reserved for future use.
Any registration for an unassigned SFMT value MUST 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 SFMT represents and how it
shall be interpreted.
Note that new RAMS functionality should be introduced by using the
extension mechanism within the existing RAMS message types not by
introducing new message types unless it is absolutely necessary.
13.4. RAMS TLV Space Registry
This document creates a new IANA TLV space registry for the RAMS
extensions. The registry is called the RAMS TLV Space Registry.
This registry is to be managed by the IANA according to the
Specification Required policy of [RFC5226].
The length of the Type field in the TLV elements is a single octet,
allowing 256 values. The registry is initialized with the following
entries:
Type Description Reference
---- -------------------------------------------------- -------------
TBD TBD This document
... ...
The registry entries are TBC.
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 MUST contain the
following information:
o Contact information of the one doing the registration, including
at least name, address, and email.
o A detailed description of what the new TLV element represents and
how it shall be interpreted.