HDTenEightyP/NetNews huggingface dataset:
From: my@laverde.nsc.com (Mike Yip)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: FDDI and ethernet address spaces
Keywords: Swap those little tiny bits ....
Date: 9 Apr 92 04:59:49 GMT
Reply-To: my@laverde.nsc.com
Organization: National Semiconductor Corp.

In article 20306@amd.com, shah@brahms.amd.com (Amit Shah) writes:
>In article <991@xlnt.COM> rasp@xlnt.com (Ron Perloff) writes:
>>Per letter from the IEEE Standards Office to the X3T9.5 committee, IEEE has agreed
>>to administer FDDI 48 bit addresses as they have for 802.3, 802.4 and 802.5, taking
>>them from the same address space so there should be no duplication.
>I believe that the IEEE addresses can be assigned by the company as they wish.
>However, the group addresses are controlled by IEEE.  Thus the IEEE controls
>the assignment of group addresses, not individual station addresses, which
>can be allocated by a company to any network they choose.

IEEE administer the {FDDI,TokenRing,Ethernet,802.3} 48 bit address to ensure
all 48 bit addresses used on the network, any network, are unique.  They
allocate a block of addresses (let's say 4K addresses) to a company and
the company itself needs make sure that the MAC address on the networking 
card is unique within its allocated block.  A company can obtain multiple
blocks if necessary.  Hopefully, the company didn't put random addresses
on the card.   ;-)

>>Note: IEEE 802.5 and FDDI addresses are both big-endian; i.e., the most significant
>>bit of each byte is transmitted first. All 802.3 and Ethernet addresses are
>>little-endian. Bridges between big-endian and little-endian addressing protocols
>>are responsible for the conversion.
>I think it is the information field which is different.  The addresses are
>in identical order in all 802 LANs.  I haven't looked it up but.....

Each byte of the 48-bit address needs to be bit-swapped (eg 10001100 ->00110001)
when the frame is going between TR/FDDI <-> Enet/802.3.

>>Having said all of this, there is always a non-zero danger that your supplier
>>will ignore or misread the standards and agreements or poorly control the use
>>of addresses, resulting in address duplication. Hardware failures can also
>>cause duplication.
>Yes.

Agree, and this is one reason why FDDI SMT provides mechanism to detect dup addresses
and possibly do something.  ;-)

---
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 
| Of course, this is my own opinion!
From: my@berlioz.nsc.com (Mike Yip)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: SMT Standard
Summary: What is new in SMT 7.0?
Keywords: SMT, ANSI, FDDI, 7.0, 6.2
Date: 6 Apr 92 02:03:13 GMT
Organization: National Semiconductor Corp.

In article <983@xlnt.COM> rasp@xlnt.com (Ron Perloff) writes:
>On the technical side, the changes between versions 6.2 and 7.x
>will not affect basic connectivity, CMT. They do significantly
>modify the form and content of frames in FBM to the extent that
>a network management station will have to understand which level
>of the draft standard a station is running in order to deal
>with the MIB. Specifically, the frame formats for SIFs and NIFs
>have been retained. The frames and protocols for SRFs and PMFs
>have been changed such that a manager designed to version 6.2
>will not be able to use those facilities with a 7.x station. Fortunately,
>there is a mechanism for identifying which level of the draft standard
>is running.
The 7.0 and 7.1 SMT frames will have a different version ID to
identify which SMT the station is running.  A management station or
hub will need to understand different version of SMT-FBM in order to
parse the content of the frames.

>The Management Information Base (MIB) is vastly different between
>the two versions. Again, a network management station would have
>to understand which version a station were running in order
>to deal properly with it.
The 7.0 and 7.1 SMT MIB will have one addition attribute which
identify the MIB version.  I think that the 7.0/7.1 MIB Version ID is
0x1.  (Sorry I don't have SMT 7.0 with me.)

Please understand that the newer version of SMT will still be able to
interoperate with version 6.2.  The end-station will probably not need
an upgrade (but of couse an upgrade is nice) but just the network
manager station.


-- 
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 
| Of course, this is my own opinion!
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Network Peripherals
Date: 16 Apr 92 12:20:45 GMT
Organization: Naval Research Laboratory, DC

In article <1636@marugw.maru.prug.or.jp>,
	sakurai@marugw.maru.prug.or.jp (Yutaka Sakurai) writes: 

> I heard that the company called Network Peripheral is developping
> FDDI concentrator.  It is first time for me to hear this name.  I
> appreciate any information about Network Peripheral.  Tnanks.
>
> Yutaka Sakurai / JF1LZQ

  I used to work with a Network Peripherals Single-attach board for an
AT/EISA 386 machine when I was working on building SMT into a
pseudo-realtime FDDI monitor last summer.  It was a much better board
than the AMD Fastcard (its main competitor).  NP uses the National
Semiconductor FDDI chipset.  I prefer the NSC chipset to the AMD
chipset because the NSC chipset has fewer bugs in it, in my
experience.  I found NP to be a good company to deal with.

  I haven't used their concentrator, but I think it should be good if
their single-attach stations are typical of their products.

DISCLAIMER: Opinions are mine, not necessarily my employer's.

Ran
atkinson@itd.nrl.navy.mil
Xref: sparky comp.dcom.lans.fddi:234 comp.protocols.tcp-ip:2528
From: koning@koning.enet.dec.com (Paul Koning)
Newsgroups: comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject: Re: ARP over FDDI and "canonical bit order"
Date: 15 Apr 92 17:50:05 GMT
Reply-To: koning@koning.enet.dec.com
Organization: Digital Equipment Co., distributed systems architecture


In article <1992Apr14.193459.28218@mcnews.mcdata.com>, ddb0248@mcnews.mcdata.com (David Beal) writes:
|>OK, somebody straighten me out here.  I'm reading the "Proposed Standard
|>for the Transmission of IP Datagrams over FDDI Networks" (RFC 1188), and I'm
|>confused.   The document says 
|>
|>	"In order to not preclude interoperability in a bridged environment,
|>	the hardware addresses in ARP packets (ar$sha, ar$tha) must be
|>	carried in 'canonical' bit order...the addresses must be bit-reversed
|>	within each octet."
|>
|>...
|>But now what happens when two FDDI hosts try to talk to each other ?
|>When one host receives a ARP request and tries to use the canonically
|>ordered source hardware address as the destination of his reply,
|>it's in the wrong bit order to put out on the FDDI network.  The responding
|>host can't detect that the other host is also on FDDI, because the
|>document says that all ARP frames transmitted on FDDI should contain
|>a hardware type field of 1, which makes everybody look like they're
|>on ethernet.
|>
|>Is this standard broken, or am I confused ?  And, while we're at it,
|>how does this work on token ring, which has the same bit order as FDDI ?
|>
|>(Please reply by email; I'll summarize.)
|>
|>- Dave Beal
|>  McDATA Corporation
|>  Broomfield, CO 
|>  ddb@mcdata.com

No, it's not broken.  It's not surprising you get confused; address encoding
is one of the most confusing aspects of the various LAN standards.

The way it works is that you have to do the necessary transformation between
the canonical form address in the ARP message and the address that the FDDI
MAC is going to put on the wire.  In some MACs, you can put them in a mode
where the addresses (DA and SA) are in fact given to the chip in canonical
form and the chip flips them.  In other MACs, you get to do the job in the
device driver.  That takes 6 lookups in a 256-byte table; obviously, the
place to do that is in ARP processing, not in the main data packet transmit
loop...

For token ring it would be nice if the same approach had been used, but 
unfortunately there were already a lot of implementations out before people
realized the problem.  So there ARP messages are sent with backwards
addresses.  Then again, there are so many other strange things that token
ring to anything else bridges have to do anyway, that ARP repair is a 
minor problem by comparison.  Not so for FDDI...

	paul
From: my@laverde.nsc.com (Mike Yip)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Daisy chaining SAS FDDI workstations
Date: 7 Apr 92 02:17:03 GMT
Reply-To: my@laverde.nsc.com
Organization: National Semiconductor Corp.

In article 34967@nntpd.lkg.dec.com, koning@koning.enet.dec.com (Paul Koning) writes:
>
>Replace "slight" by "massive" and I might agree with you.  But the PCM
>algorithm in SMT is fundamentally a two-party algorithm.  No "slight"
>change is going to transform it into an N-party algorithm!
>
>	paul

I agree with Paul.  The PCM protocol is a 2 way handshaking between the two
ports.  But if we forget about the "communication" and have a master station
to "tell" the slave stations on a loop to to start (PC_ACTIVE) then things
can be up and running.  Well this sounds simple, but it is actually harder
to do, but it is not impossible.  ;-)

---
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 
| Of course, this is my own opinion!
Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: FDDI and ethernet address spaces
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 11 Apr 1992 18:29:18 GMT

In article <1992Apr10.191448.5217@berlioz.nsc.com>, my@laverde.nsc.com (Mike Yip) writes:
> 
> >I suspect the SMT duplicate-MAC-address obsession comes from the original
> >ANSI FDDI MAC standard which said 16-bit addresses were required and
> >48-bit addresses optional.  It appears the early FDDI ideas were based on
> >the wonderful IBM gee-look-how-much-fun-it-is-to-locally-administer-
> >hardware-addresses philosophy.  That has been reversed, making 48-bit
> >addresses required, and 16-bit optional and so unsupported by (as far as I
> >know) all current FDDI products.
> 
>At the InterOp trade show, all (I think) the vendors used the 48-bit address.  
> I am not sure if anyone really use the 16-bit address to do real work.

That's what I meant.

The new MAC standard requires each and every MAC to have a unigue,
"globally administratrated" IEEE address, and SMT wants a unique 8-byte
station ID.  There is no profit for anyone in fiddling around with
locally administrated 16-bit addresses.  Very few people have so much time
on their hands that they like assigning MAC addresses to stations.

> >>  ...[bit swapping discussion]....
> >The place where this bit swapping madness hurts is not in bridges.
> >Everyone knows and understands that problem, and some MACs have hardware
> >support for it (e.g. DEC/Motorola). 
>
> There will be more MACs doing bit swapping in the furture.  ;)

I don't think it's worth the silicon for a station.  It takes a 256-byte
table and about 24 instructions on your favorite RISC to bit-swap a 6-byte
MAC address.  Those 24 instructions can be hidden among the instructions
that you use to build the MAC header from the ARP table.

You must always be prepared to bit swap MAC addresses in software in any
case, because of SMT, even if you don't care about TCP/IP.  

I have tried to use the DED/Mot. bit swapping, and found it less than
useless.  It is far faster for a workstation to ignore that "feature."

Perhaps MAC address swapping hardware would be useful for an FDDI-FDDI
bridge trying to break 500,000 packets/second.  I don't know about bridges,
except that I think they are a stupid idea.


Vernon Schryver,  vjs@sgi.com

Xref: sparky comp.dcom.lans.fddi:229 alt.security:2757
From: al@escom.com (Al Donaldson)
Newsgroups: comp.dcom.lans.fddi,alt.security
Subject: Re: FDDI SMT Standard
Date: 14 Apr 92 15:41:59 GMT
Reply-To: al@escom.COM (Al Donaldson)
Distribution: usa
Organization: ESCOM Corp., Oakton VA (USA)

In article <2002@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>  The other cute thing about using FDDI rather than Ethernet in
>trusted systems is that because the data rate of FDDI is so much
>higher, the covert channels inside the FDDI protocol are also
>correspondingly higher.

I would say "may be higher" rather than "are also correspondingly
higher."  It doesn't follow that they will be measurably higher and
I would doubt very much that they would be proportionally higher.

The reason is that covert channels in LAN-based systems depend more
on speed of the attached computing equipment (and software) than on
the transfer speed of the cable itself.  This is perhaps analogous
to what would happen in a single-processor system if you increase
the speed of the memory bus but *not* the cpu -- you might increase
covert channel bandwidth (due to lower wait states), but the effect
would not be proportionally higher (to the memory bus increase)..

Covert channels involve a shared resource and two processing entities.
One entity modulates information onto the shared resource using some
protocol and the other demodulates it.  For example, if the shared
resource is the cable bandwidth itself, then a (noisy) channel might
be for host 1 to load the LAN to a certain utilization to signal a "1"
and remove the load to signal a "0".  The bandwidth that might be
achieved depends on a lot of things, including how fast the sending
host system can pump packets onto the LAN.

For additional information, refer to the paper I co-authored with 
John McHugh and Karl Nyberg, in the proceedings of the 11th National 
Computer Security Conference.

Al
From: my@laverde.nsc.com (Mike Yip)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: FDDI Concentrator Performance
Keywords: Concentrator performance, FDDI, router
Date: 17 Apr 92 00:34:29 GMT
Reply-To: my@laverde.nsc.com
Organization: National Semiconductor Corp.


In article Rolly_Noel@quick.ucs.ualberta.ca (Rolly Noel) writes:
>One vendor mentioned that all concentrators are not equal in performance with
>their product delivering "up to 80%".
>
>Is this an issue we should be sensitive to in choosing a concentrator?
>
>Does anyone have performance data on FDDI concentrators?

I am not sure how one can measure the "performance" of concentrators.
The FDDI concentrators only deal with connections, not packet routing
or forwarding.  (Routers and bridges do packet stuff.)  Therefore, there
should not be any frame/sec type of number.

I think that what people should look for in a concentrator is reliability,
expandability and manageability.  The concentrator better be well built and
durible.  It should runs for a looooong time without any services.  My 
ethernet repeat under my desk is working for years without any problem.  I
don't even know how it looks like anymore.  the concentrator should do the
same.

The concentrator also needs to be expandable since you will probably want to
put more and more stations on the ring.  (Well, you can also buy another
concentrator.  ;-)  It also needs to be expandable in terms of media types.
100Base-T, the twisted-pair version of FDDI, is just coming out soon and
you would want your concentrator to be able to plug in 100Base-T ports.  Same
reason applies to single-mode fiber to connect building together.  Some
concentrator vendors will also put routing and/or bridging and/or ethernet on
the same hub.  It might be useful to get something like that.

-- Mike





---
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 
| Of course, this is my own opinion!
From: my@laverde.nsc.com (Mike Yip)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Daisy chaining SAS FDDI workstations
Date: 9 Apr 92 04:48:22 GMT
Reply-To: my@laverde.nsc.com
Organization: National Semiconductor Corp.

In article 23022@amd.com, shah@brahms.amd.com (Amit Shah) writes:
>In article <j9dqmr8@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>>The justification for PCM and SMT in general is "fault domain isolation",
>>locating whatever is broken when things don't work right.
>
>If implemented ***correctly*** then the justification is not just "fault domain
>isolation"; it is also fault detection and (possibly) correction.

Fault isolation and fault detection, yes.  But, I don't see how it can
do fault correction.  Can you (Amit) suggest how PCM does fault correction?

I agree that PCM makes SMT a bit more complicated, but it also buy you
some better facilities, like LCT and, may be MAC Loopback.  I think that
it is a better practice to test the connection before going into the 
network.  But is PCM the best way to do that?  I don't know.  

---
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 
| Of course, this is my own opinion!
Newsgroups: comp.dcom.lans.fddi
From: stephan@idt.unit.no (Eirik Morten Stephansen)
Subject: Information about FDDI ............
Organization: University of Trondheim, Norway
Date: Mon, 6 Apr 92 18:37:09 GMT


TO EVERYONE WHO WANTS INFORMATION ABOUT FDDI.

I just want to suggest to everyone who wants information about FDDI
to read the ISO internation standard ISO 9314-1,2,3.

E.S.
From: ciarfela@vega.ucsb.edu (Ciarfella)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: SMT Standard
Date: 9 Apr 92 21:49:12 GMT
Organization: University of California, Santa Barbara

In article <995@xlnt.COM> rasp@xlnt.com (Ron Perloff) writes:
>mandatory. They were not mandatory in earlier versions. Without
>PMF Get responses implemented on the end-stations, a management
>station working through a proxy agent cannot obtain the
>information it needs. Since a number of organizations believe in
>using proxy agents to manage FDDI sub-networks of enterprise
>networks, end-station vendors, or board vendors selling to
>end-station vendors, will be at a distinct disadvantage in the
>marketplace if they do not move up to version 7.x.
>

I don't understand why it was necessary to add pmf's to the standard.

Wouldn't it have been easier to rely on snmp and OSI-based management
protocols to gather this information?  It might have been sufficient
to provide only a rich set of management attributes without the protocol.

PMF's, in my view, seem to just add more complexity to the standard and yet
another level of management (yolm).  

Paul Ciarfella

University of California 
	and
Digital Equipment Corporation


Xref: sparky comp.dcom.lans.fddi:239 comp.protocols.tcp-ip:2537
From: neerma@cod.NOSC.MIL (Merle A. Neer)
Newsgroups: comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject: Re: ARP over FDDI and "canonical bit order"
Date: 16 Apr 92 15:10:49 GMT
Article-I.D.: cod.3775
Organization: Naval Ocean Systems Center, San Diego

>|>for the Transmission of IP Datagrams over FDDI Networks" (RFC 1188), and I'm
>|>confused.   The document says 
>|>
>|>	"In order to not preclude interoperability in a bridged environment,
>|>	the hardware addresses in ARP packets (ar$sha, ar$tha) must be
>|>	carried in 'canonical' bit order...the addresses must be bit-reversed
>|>	within each octet."
>|>


All this talk about bit-swapping has me paranoid. I have an FDDI ring
and some ethernets..I have Timplex bridges connecting the two. My
hosts do no swapping of bits...neither do the bridges....all works well.
That is to say, if I generate a packet from my Ether host to the
FDDI host's 48 bit FDDI address, it gets there...yeah, sure bit 40
shows up first...but, who cares once the 48 bit address is put back 
together it looks just like new! I can understand the concern with
multicast since apparantly multicast numbers are defined in terms of
transmitted bit order (WHY?)...so mulitcasts on token and ether are
different...so if I want to form a group of FDDI hosts and ethernet
hosts I have to bit swap if I want to follow IEEE addressing scheme...but
I could do this without any swapping at the bridges and certainly without
swapping the whole damn world....



Where am I losing it? I am trying real hard to understand the problem
that bit swapping solves but (obviously) having difficulty..

Also, is bit swapping at the bridges prevalent in other products?

Merle
Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: SMT Standard
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 13 Apr 1992 23:51:03 GMT

In article <1992Apr11.005816.14490@berlioz.nsc.com>, my@laverde.nsc.com (Mike Yip) writes:
> ...
> > ... As I understand it, and my understanding
> >is pretty limited, there should be only one SMT entity per device (i.e. not
> >per connection).  To me that implies that SMT would often be implemented in
> >a driver on host computers since a single host could have more than one
> >ring connection.  Is that true, and therefore would imply that only certain
> >drivers would have to be upgraded?  
> 
> I am not sure, but I think that you can think of SMT as an entity per host per
> network.  Meaning if you host have two FDDI connections to two different
> network
> (2 different FDDI rings), then 2 entities of SMT are needed.  But, of course,
> one device can handle both SMT, depending on the implementation....


Exactly.  In the SGI implementations, there is one SMT daemon which handles
all the low speed state machines (e.g. RMT) for all rings to which the
machine is connected, but with independent state vectors.  CMT is done in
the drivers, again with common code but separate abstract machine state.

If your machine is connected to more than one dual ring, it must have a
different "station ID" for each dual ring.  Otherwise bad things would
happen if the user connected both interfaces to the same dual ring.  (This
is sometimes needed with ethernets, and will no doubt be needed in similar
circumstances on FDDI rings.)

Think of FDDI as an overly complicated, excessively expensive, 10X faster
ethernet.  As long as you don't talk to the specialized FDDI hardware
makers you won't be far wrong or contradicted.


Vernon Schryver,  vjs@sgi.com