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