|
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] 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 |