[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available
Hi
I have read through the updated draft and have a few comments and requests for your consideration.
In general (as I hinted before) I would like this draft to not just discuss the unicast version of RAMS, instead I would like it to also incorporate the multicast version into the framework.
I have looked into this and I would say that support for the multicast alternative as described in
http://tools.ietf.org/id/draft-johansson-avt-mcast-based-rams-00.txt
is fairly straightforward to add to the existing framework, I will describe in brief below the key additions that I see today.
The title of the draft would then become "Rapid Acquisition of Multicast RTP Sessions". I can offer to add the necessary parts in the document that describes the multicast based version of RAMS.
Packet structure:
In the draft, three FMT's are defined for the RAMS R,I and T messages. I wonder if it would be better to use one just one FMT for this "family" of messages and use a subtype to define R, I, T (or any other message). This was also brought up during the break-out session in SF.
Also I would consider a version field as well as there is a chance that things need to be changed in the future and TLV extensions may not solve all backwards compatibility issues in a satisfactory way (changing version number should not be too easy though, TLV elements should be the first choice).
With this in mind the first 32 bits may look like:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ver |subtype| flags .... |reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example 3 bits are used for the version number and 5 bits are used for the subtype but there may be a better distribution here. The number of bits for the flags and reserved field depends on the subtype
The subtypes would be encoded as
RAMS-R = 0
RAMS-I = 1
RAMS-T = 2
Figure 2:
A flow diagram that describes the multicast version to be added.
Figure 3:
A description that describes the multicast version to be added.
Section 6.4: Failure cases
An alternative to RAMS-T in the multicast version of RAMS is the use of IGMP-Leave (details about this are needed)
Section 7.1 RAMS Request
Here the 32 bit header is added (with subtype=0) and possibly the preference and or support of the multicast and the unicast version of RAMS can be defined in the flags field. The latter is likely needed as the SDP's are likely only declarative.
Section 7.2 RAMS Information
Here the 32 bit header is added (with subtype=1) and the MSN,S and Response field is put in the flags field.
An additional TLV element is added that includes a multicast address and possibly other information such as expected delay until the multicast RAMS starts. This field is mandatory if the multicast address for RAMS is described in this way.
Section 7.2 RAMS Termination
Here the 32 bit header is added (with subtype=2)
Note that RAMS-T may not be needed in the multicast version of RAMS (T.B.D)
Comments to my comments are welcome
Regards
Ingemar
*******************************************
Ingemar Johansson
Senior Research Engineer, IETF "nethead"
EAB/TVP - Multimedia Technologies
Ericsson Research Ericsson AB
Box 920 S-971 28 Luleå, Sweden
Tel: +46 (0)10 7143042
ECN: 852-43042
ECC: 852-19042
Mobile: +46 (0)730 783289
Visit http://labs.ericsson.com !
*******************************************