Re: [RE] Stream identification at the MAC SAP
Comments to your comments ...
On 11/11/04 10:41 AM, "Shvodian William-r63101"
<bill.shvodian@FREESCALE.COM> wrote:
> Just an opinion, but ...
>
> 1. None of the higher layer services running on ethernet/802(anything)/IP
> have any idea what to do with isochronous data ... so it is not surprising
> that there are no service parameters that deal with this.
>
[Bill Shvodian] I don't think that is quite true. RSVP can be used to
reserve bandwidth for a stream. From rfc 2205: "An RSVP session is defined
by the triple: (DestAddress, ProtocolId [, DstPort])." This information
could be used to identify an isochronous strream.
[MJT] Yes, but this is strictly a end-point to end-point reservation. The
network does not participate in the admission control//resource allocation
stuff. RSVP/RTP/RTCP things make all kinds of assumptions (basically that
the network is IP only and is basically best-effort-only). ... and yes, the
"ProtocolId, DestPort" pair *can* be used for stream identification ... but
this is getting way beyond an 802 disscussion so I think we should just drop
it for now.
2. At the guts of ResE, I expect we will need a unique EtherType to
indicate an isochronous packet, just like you do for MAC control frames.
[Bill Shvodian] Identifying it as isochronous is one thing. Identifying
which stream is another. You may have two video streams and multiple audio
streams between two nodes, but since the reservations and treatment may be
different depending on the type of stream.
[MJT] The stream identification is indeed something that needs to be done,
but I think the existing 802.2 SAP IDs are way too small. Isoch stream IDs
should be fairly robust. I would argue that they should be identified by a
multicast destination address ... on 802 this would allow up to 2^42 streams
(less all those used for other purposes).
3. I expect there will have to be a NEW service interface for isochronous
data (yet another reason for this to be done in 802.3). This might look
just like the existing MA-UNITDATA.request, except with scheduling
parameter(s).
[Bill Shvodian] I agree. I just wish that 802.2 had agreed to make the
change so that ALL 802 standards would use the same defined parameters,
rather than having one for RE, one for 802.11e, one for 802.15.3, etc, etc.
[MJT] Perhaps so. On the other hand, do you think we could use a SNAP header
to build an 802.3-specific method for labeling Isoch protocols? I could
imagine one that is used to tag all IEC 61883-type packets (the normal
tagging and formatting system for consumer-electronics type streams in
1394).
--
---------------------------------------------------------------
Michael D. Johas Teener
http://public.xdi.org/=Michael.Johas.Teener - PGP ID 0x3179D202
--------------------- www.plumblinks.com ----------------------