[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

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

602.0. "DECNET NSAP?" by TAV02::YAIR (Yair Tsoran, Industry Israel, DTN 882-3094) Mon Jun 08 1992 10:49

Hi,

DECnet, when running over ETHERNET is using "protocol type" field as an 
identifier. However, when running over FDDI & Token Ring this field should
be replaced by NSAP. 

1. What is DECnet NSAP?
2. Does the DECBRIDGE 500/600 convert the protocol type field in ETHERNET
   packets according to the correct NSAP over FDDI? .i.e. does it take
   ETHERNET packets of protocol type = 60-03 and convert them to the "DECNET
   NSAP"?


		Regards
					Yair Tsoran
					ISRAEL

Cross posted in DECNETVAX, FDDI, TOKEN_RING, DNT
T.RTitleUserPersonal
Name		DateLines
602.1KONING::KONINGPaul Koning, A-13683Mon Jun 08 1992 11:0322
"NSAP" isn't right, that belongs in the routing layer header (in OSI routing).
I think what you meant is "DSAP".

IEEE 802.2 DSAPs are only 7 bits, so there aren't enough available.  To solve
this problem, IEEE created a second level of addressing, called "SNAP".
This has a DSAP value of AA, and just after the LLC header are 5 more bytes
which are the "Protocol ID".  The first three are taken from the address
block of whoever assigns it, so DEC Protocol IDs generally look like
08-00-2B-xx-yy.

However...  There is a special convention for converting Ethernet Protocol Types
into SNAP.  This is from the TCP/IP world (RFC 1042, 1188).  This uses a
Protocol ID of 00-00-00-xx-yy to correspond to Ethernet Protocol Type xx-yy.
So Phase IV DECnet packets, which are Ethernet format packets, appear on
FDDI as SNAP frames with Protocol ID 00-00-00-60-03.

And yes, bridges take care of this.  For that matter, so do the drivers; if
you use the QIO (or equivalent) to enable "protocol type" 60-03, exactly as
you would have on an Ethernet device, the FDDI driver will accept request and
use Protocol ID 00-00-00-60-03 instead.

	paul
602.2OSAV20::IZUTANIKenji Izutani,Tech.Consul.,CSEC,DEC-JapanThu Jun 18 1992 05:419
I wonder which is the industry standard, either "00-00-00" or "08-00-2B" for 
the first three octets of OUI in SNAP SAP.

Also I wonder if there is a special OUI for AARP on FDDI.

Hope to hear on this.

Regards,
Kenji
602.312345::thomasThe Code WarriorFri Jun 19 1992 11:4110
Neither.  An OUI of 00-00-00 indicates that you are using encapsulated Ethernet.
An OUI of anything else means you talking a protocol specific to the vendor
who owns that OUI.

Now the exception, since appletalk arp uses an OUI of 00-00-00 on CSMA/CD,
you need to use a different OUI on FDDI so that it can be translated back 
when forwarded back onto Ethernet.  So an OUI of 00-00-F8 is used (this OUI
is expressly prohibited from appearing on 802.3)

Check out RFC 1188.
602.4LEVERS::ANILMon Jun 22 1992 20:1120
    By the way, RFC-1122 specifies what has now become "encapsulated
    Ethernet" on FDDI as a way of doing IP over 802.3/.2, thus also having
    to make the requirement that stations using this format should be
    prepared to receive ethernet format responses.
    
> Now the exception, since appletalk arp uses an OUI of 00-00-00 on CSMA/CD,
> you need to use a different OUI on FDDI so that it can be translated back 
> when forwarded back onto Ethernet.  So an OUI of 00-00-F8 is used (this OUI
> is expressly prohibited from appearing on 802.3)
    
    Not quite..  The 00-00-00 OUI AARP packet, when received on Ethernet,
    stays that way on FDDI as well back out to Ethernet.  This is the case
    for Appletalk-2 AARP.  It's the Appletalk-1 AARP, which is ethernet
    format, that is changed to 00-00-F8.  This OUI indicates to the outgoing
    bridge (back out to Ethernet): convert me unconditionally to ethernet
    format.  Note that this does not yet seem to be standard in all
    transparent FDDI-Ethernet bridges; our bridges are the only ones I know
    for sure that fix this problem.  (I *think* Fibercom does too)
    
    Anil