| Yes, since that is the standard for how to deal with such protocols. This is
being added to 802.1d; I'm not sure how close to finished it is. Or more
precisely, it is Appletalk V1 that is (and has been) translated to OUI 00-00-F8,
not Appletalk V2.
Why, did you have the impression that this was temporary or changing?
paul
|
| Paul,
Thank you for your input. Now, I can make sence.
>Why, did you have the impression that this was temporary or changing?
First of all, 00-00-F8 was DEC proprietary, so I was concerned in the case if
our bridge co-operate with other vendor's which has the same idea for
translating Apple talk.
Second, I've got recently a very expensive toy which can see FDDI frame and
I was playing to see the frame on the ring when I put the frames into NI port
on my DB6xx.
The frame I generated at NI was DA/SA/LEN/aa/aa/03/000000/80f3/000.....but I
saw the same OUI 000000 in the translated fddi frame. This looks like Apple
talk V1 or V2??
Naoki
|
| Ok, some more background.
The basic Ethernet to FDDI translation works as follows:
1. 802 format packets come across with the LLC part unchanged.
2. Ethernet format packets are converted into 802 SNAP packets with a
Protocol ID consisting of 3 bytes of zero followed by the Ethernet Protocol
Type.
The above conforms to RFC 1042 and RFC 1188, and will result in transparent
operation for most protocols. (In particular, for any protocol that
adheres to the rules for the use of 802 format packets given in RFC 1122.)
Appletalk, or rather Apple ARP (one of the protocols that make up Appletalk)
does not conform to the rules of RFC 1122 and therefore does not work
with the above translation. Therefore, our bridges have a table of protocols
that require special handling. Normally that table contains a single entry,
the protocol type for Aple ARP (80-F3). Bridges that have this table use
a different "Rule 2":
2. For Ethernet format packets, look in the special handling table. If the
Protocol Type is found in that table, translate to a SNAP packet with
Protocol ID of 00-00-F8 followed by the Protocol Type; otherwise, translate
to a SNAP packet with Protocol ID of 00-00-00 followed by Protocol Type.
To see why this is done, consider the rules for translating from FDDI
to Ethernet:
1. If the packet is SNAP with Protocol ID beginning with 00-00-F8, translate
to Ethernet format.
2. If the packet is SNAP with Protocol ID beginning with 00-00-00, see if the
last two bytes of the Protocol ID are in the special handling table.
If not, translate to Ethernet format. If it is in the table, leave the
packet as an 802 format packet.
3. Otherwise, leave the packet as an 802 format packet.
The reason for this complexity:
On Ethernet, AppleTalk V1 uses Ethernet format packets with 80-F3 as the
Protocol Type. V2 uses 802 SNAP format packets with 00-00-00-80-F3 as the
Protocol ID. If you translate to FDDI format without the table, both
packets would end up as SNAP frames with a Protocol ID of 00-00-00-80-F3,
and would be translated back to Ethernet packets at the second bridge.
Most protocols that use both formats (e.g., TCP/IP) treat Ethernet format
and 802 SNAP format frames with P_ID of 00-00-00-xx-yy as equivalent, which
is what RFC 1122 says should be done. Appletalk doesn't; it treats them
as two separate protocol versions which are NOT compatible. So the normal
bridge action breaks things.
The solution is the table-driven rules. Using the table, an Appletalk V1
frame ends up on the FDDI with Protocol ID 00-00-F8-80-F3, and the Appletalk V2
frame has 00-00-00-80-F3. At the next bridge, each is translated back into
its original form and the version information is preserved.
Digital originally developed this solution to the AppleTalk problem; we
proposed it to IEEE. IEEE 802.1 has adopted it (with some small changes;
the description above should reflect those changes). So it is NOT a proprietary
solution, but should work with any transparent bridge that implements the
current IEEE 802.1d rules.
The 00-00-F8 block belongs to Digital, as you pointed out. When IEEE adopted
the AppleTalk fix I described, we donated the 00-00-F8-xx-yy protocol
identifiers to IEEE for use in this algorithm. (We still can use that block
for other purposes, though, for example to assign 48-bit data link addresses.)
If you're seeing a SNAP frame with 00-00-00-80-F3 on an Ethernet, that's
Appletalk V2. You should see the same frame on the FDDI; that indicates
you have up to date bridges that have the Appletalk fix implemented and have
the right table entry.
paul
|