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

Re: [RE] Stream identification at the MAC SAP



Title: Re: [RE] Stream identification at the MAC SAP
To add something such as a stream identifier that is the same across the MACs, the place to do it is 802.1 rather than 802.2. It could be done with a type field (which identifies this as a stream header) followed by one or more fields to identify the stream. I haven't seen enough to determine that this is necessary or desireable, but if it is then it should be done in 802.1 not 802.2. Pat
-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG]On Behalf Of Shvodian William-r63101
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
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.   
  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.