Re: [RE] Stream identification at the MAC SAP

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

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

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