|
Bill,
For those that are unfamiliar with them, I would
encourage
what you suggest. However, I think I already have a
good
feel for these too and they appear much to divergent
from
802.3 to be easily incorporated.
From the little that I have
heard, I also understand that
802.9 would also require dramatic changes to 802.3 and
is
therefore not applicable. However, I would be
interested
in reading for myself, if this reference were
available.
Some relevant review material would be
the classA/classB/classC
classes supported within 802.17. I believe this
standard will
be on the CD in November.
From talks with my IEEE contacts, I also understand
that
previous standards (if judged to be appicable, by
the Chair)
can be obtained for review
by participants.
DVJ
David V. James
3180 South
Ct
Palo Alto, CA 94306
Home:
+1.650.494.0926
+1.650.856.9801
Cell:
+1.650.954.6906
Fax: +1.360.242.5508
Base:
dvj@alum.mit.edu
Well, add FDDI-II and ATM to the reading list,
then...
Bill
Matt,
>> Maybe that says
something.
Probably does. It says that it would be good
to read what they have done, so as to not repeat
the
same mistakes. A good read is always
valuable.
DVJ
David V. James
3180 South Ct
Palo Alto, CA
94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax:
+1.360.242.5508
Base: dvj@alum.mit.edu
So, there was a bunch of work on trying to make isochronous LANs in
the IEEE, and now all of that work is in hibernation and not in use.
Maybe that says something.
-
Matt
Jose:
802.9 is a good example for Bill's question. I was a member of
the 802.9 WG when the group completed the work on 802.9a (ISLAN16-T) and
.9b which I forget the formal name, but defined the Access Unit AU which
was the I/F to other network types. This WG by the way is also in
hibernation. 802.9a defined an interface between .9a TE's and
servers to a .9b AU and we did take exception to providing compliance with
802.1 in our .9b AU PAR for the isochronous and multiservice modes of
operation. The third mode was the 10BASE-T mode which of course
complied with .1. The modes that incorporated isochronous traffic
claimed compatibility to ITU-T defined ISDN transport and used the Q.93x
family of signalling protocols.
As you state, the .9 group has been disbanded for many years and there
has been no effort to to revise these documents.
Regards,
Richard
Brand
JMB wrote:
Have you revised the documents of the
IEEE 802.9 ISOCHRONOUS LANs? <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office"
/>
This Working Group, now disbanded,
developed standards for Isochronous LANs, called "Iso-Ethernet", which
combines the properties of IEE 802 LAN and ISDN networks (Plesiochronous
Digital Hierarchy). I believe that they can have interesting
information, since they developed an isochronous system of local
network.
With
respect to the second question, the protocol able to identify data
streams is the LLC type 2 (802.3), by means of the P/F bit.Jose Morales Barrosojmb@ieee.org
----- Original Message -----
Sent: Thursday, November 11, 2004
12:33 AM
Subject: [RE] Stream
identification at the MAC SAP
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
|