| Title: | FDDI - The Next Generation |
| Moderator: | NETCAD::STEFANI |
| Created: | Thu Apr 27 1989 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2259 |
| Total number of notes: | 8590 |
We currently are bidding to interconnect some Ethernet LANs in an industrial
campus. OUr proposal is based on an FDDI ring with some DECbridge 900MX.
Some of our competitors propose Ethernet-only links, but the customer would
prefer our approach, if we can commit ourselves on the following point:
He will use various Ethernet/802.3 protocols and want to be sure they will be
transmitted without any problem between Ethernet LANs thru the FDDI ring.
I already have verified it is OK for most of them:
- some are purely based on MMS and as so, are supposed to be OSI compliant
- I could get frame structures for some others and could verify they were
either 802.3/802.2 compliant, or Ethernet V2 (with correct usage of fields)
But I've some other left that are claimed 802.3/802.2 compliant but when I
looked more precisely, I've found:
- the 802.3 header is OK (DA, SA, "true" lgth, not counting padding)
- the 802.2 LLC format has been "freely" implemented:
no standard SAP's (e.g. OSI "FE")
nor SNAP type SAP ("AA") followed by a registered OUI;
Instead they used DSAP or SSAP like "24" or "26" (none of the standardized
ones, as far as I know all of them), and I guess, no SNAP
Can such a frame be transparently forwarded or is there any potential
problem.
I guess we will be unable to talk that protocol to an FDDI-linked system
but our only wish for that protocols is to talk from Enet to Enet.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1387.1 | KONING::koning | Paul Koning, B-16504 | Mon Jun 27 1994 19:07 | 36 | |
The Ethernet/FDDI translation (as implemented in all our bridges, the 900 included) doesn't care whether the SAPs are standard or not. It should handle the case you mentioned just fine. It even handles cases that are far more screwed up, such as the "raw 802.3" mode of IPX. The Ethernet to FDDI translation process first check if the packet is 802.3 or Ethernet format (based on length/proto being <=1500 vs. > 1500). If 802.3, it simply takes all that follows and puts it into an FDDI packet. In other words, the result is an FDDI packet with the identical LLC header, whatever that was. (One exception: if "raw 802.3 IPX" handling is enabled, packets with DSAP = SSAP = 0xFF are turned into IPX frames.) The length of the FDDI frame is derived from the length field in the 802.3 header. So in your example, if you have a packet with DSAP of 24, it looks somewhat like this on Ethernet: 08-00-2b-11-22-33 08-00-2b-aa-11-75 00-41 24 24 03 11223344.... (00-41 is the length; 24 24 03 is the LLC header, a UI frame in this case, not that it matters; and 11223344... is the user data.) The resulting FDDI frame, ignoring confusing stuff like address reversal, would be: 50 08-00-2b-11-22-33 08-00-2b-aa-11-75 24 24 03 11223344.... with a length (from start of LLC header to end of data) of 41 hex (65 decimal). And indeed that's the corresponding LLC frame on FDDI. So (a) yes, your application frames will go from one Ethernet to another perfectly well, and (b) you WILL be able to talk to those nodes from the FDDI. In fact, given the way the device drivers are designed, the same program should work on either device with no change other than referring to the different device name. paul | |||||
| 1387.2 | Thanks... | LFOIS1::MOUSSU | so unusuaL terM | Tue Jun 28 1994 08:23 | 5 |
for fast & precise answer. Regards Laurent | |||||