Re: [RE] Stream identification at the MAC SAP
ERRATA below :-)
Dirceu Cavendish
NEC Labs America
10080 North Wolfe Road Suite SW3-350
Cupertino, CA 95014
Tel: 408-863-6041 Fax: 408-863-6099
-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG]
On Behalf Of Dirceu Cavendish
Sent: Thursday, November 11, 2004 12:32 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] Stream identification at the MAC SAP
Comments below <DC><DC/>
Dirceu Cavendish
NEC Labs America
10080 North Wolfe Road Suite SW3-350
Cupertino, CA 95014
Tel: 408-863-6041 Fax: 408-863-6099
-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG]
On Behalf Of Shvodian William-r63101
Sent: Thursday, November 11, 2004 10:41 AM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] Stream identification at the MAC SAP
See comments below...
_____
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG]
On Behalf Of Michael D. Johas Teener
Sent: Wednesday, November 10, 2004 7:44 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] Stream identification at the MAC SAP
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.
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.
<DC> Now we are going into architectural issues, which at some point we
will have to dive into. At the last F2F meeting, we started to discuss
architectural issues by id-ing what belongs to .1 and .3. I guess we
should pick from there, and refine each requirement - discussing
possible implementations. For instance: an ethertype may id an
iso-frame, which will immediately trigger a particular frame processing
scheme within .3 - arrival time stamping, to support identification of
iso channel.<DC/>
<DC><DC> I meant time identification to support frame dropping in case
of late frames<DC/><DC/>
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.
<DC> Once .3 requirements are identified, these have priority in a
subsequent study on possible technical solutions.IMHO<DC/>
<DC> Rgds to all,
Dirceu <DC/>
On 11/10/04 3:33 PM, "Shvodian William-r63101"
<bill.shvodian@FREESCALE.COM> wrote:
I have a general question on the MAC-SAP interface for RE. All 802
standards are required to support the 802.2 interface. The 802.2
interface does not provide a way of identifying an isochronous stream to
the MAC at the MAC SAP. When 802.2 was up for reconfirmation last year
I suggested that they add a stream identification parameter that could
be used for protocols that provide isochronous services like 802.15.3 or
now 802.3 RE. 802.2 rejected the comment.
Has anyone given a thought to how streams would be identified at the
MAC-SAP? Would there be optional parameters added beyond those provided
by the 802.2 interface? The current parameters from 802.3 are listed
here:
MA-UNITDATA request (
source_address,
destination_address,
routing_information,
data,
priority,
service_class
)
and from 802.3:
MA_DATA.request (
destination_address,
source_address,
m_sdu,
service_class
)
Thanks.
Bill
--
Michael D. Johas Teener
-- http://public.xdi.org/=Michael.Johas.Teener --- PGP ID 0x3179D202