Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS)

Bill,

Please send me the draft for review once you are done with your editorial path, before we send it out for review I would like to add my changes to the draft.

Zeev

From: Bill Ver Steeg (versteb) [mailto:versteb at cisco.com]
Sent: Tuesday, March 31, 2009 11:46 AM
To: avt at ietf.org; Zeev Vax; Tom.Van_Caenegem at alcatel-lucent.be; Ali C. Begen (abegen)
Subject: Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields

One of the primary action items arising from the review of the Rapid Acquisition of Multicast Streams draft is to identify which fields are mandatory (and thus fixed format) and which fields are optional (and thus TLV format). Here is my take on the matter. Once we reach consensus, I will update the draft.

I have also included a description of the requested "motivating text" for the fields that do not already have such text in the document. Please let me know if I am on the right track.

There is currently no version number in the messages. Ali and I do not think that this is a problem because we can add new TLVs as needed. I want to be sure we intentionally decide on this point rather than back into it accidently. Any comments?

We have 3 messages -

RAMS-Request

Max Receive BitRate - mandatory

Min Buffer Fill Requirement - optional ( Add wording - The receiver may have knowledge of it's buffering requirements. These requirements may be application or device specific. For instance, the receiver may need to have a certain amount of data in it's application buffer to handle interdependency within the data. If the RS knows the buffering ability of the receiver, it may more precisely tailor the burst to the client. The methods used by the receiver to determine this value is application specific, and thus out of scope. This mechanism can be used by the receiver to signal the sender, if the receiver has such knowledge )

Max Buffer Fill Requirement - optional ( Add wording - The receiver may have knowledge of it's buffering requirements. These requirements may be application or device specific. For instance, one receiver may have more physical memory than another receiver, and thus can buffer more data. If the RS knows the buffering ability of the receiver, it may more precisely tailor the burst to the client. The methods used by the receiver to determine this value is application specific, and thus out of scope. This mechanism can be used by the receiver to signal the sender, if the receiver has such knowledge )

RAMS- Inform

message Sequence Number - mandatory

Response - mandatory, will include an enumerated list of response codes - 0 is succeed, non zero is an error code. We will enumerate a list of error codes, and note that additional error codes are possible using vendor-specific TLV fields. The enumerated errors will include [No server resources, No network resources, bad RMS-R request, WHAT ELSE????] Note - we have removed the "join now semantic, as that is captured in the "earliest join time" field.

Reserved - mandatory - must be all 0s

Max Burst Bitrate - mandatory

Rapid Acquisition Duration - mandatory - 0 means "join now" (Add wording to reflect that this is the server's current value, and can be changed by subsequent RMS-I. Add wording to reflect that the RS can't consume resources forever and needs to deterministically stop the flow. The RS MUST terminate the flow at this time, even if does not get RMS-T from the RR. )

Extended RTP Sequence Number of First Burst Packet - mandatory

Earliest IGMP Join Time - optional (we should consider making this mandatory in at least one RMS-I, as the client needs to eventually join)

Rams -Terminate -

Extended RTP seqnum of First Multicast packet - optional (intent is to tell the RS the seqnum at which to stop the burst, but leave the session open. If the field is not present, it means "stop now")

Bill VerSteeg

Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields