HDTenEightyP/NetNews huggingface dataset:
From: mj_peterson@pnl.gov (Marty J Peterson - WI7R)
Newsgroups: comp.dcom.lans.fddi
Subject: Opinions for FDDI TW/PR Standards
Date: 9 Apr 92 16:17:27 GMT
Article-I.D.: oracle.1992Apr9.161727.29692
Distribution: usa
Organization: Battelle NW Labs

We are in the middle of designing a brand new state-of-the-art (or at least
up-to-date) scientific laboratory for research in molecular science and 
environmental restoration.  Plans are to house in this facility some high
performance resources, etc.  We are being given the opportunity to start 
fresh and design the latest technology for the networks.  My plans are to 
run FDDI to each office, and I have not kept up with the latest 
standards in the areas of TW/PR FDDI.

My question to the net is this:

1.  Is the wiring type for TW/PR FDDI being discussed in the standards bodies???
If so who could I contact to obtain the information (even if preliminary, 
unapproved,  etc)?
2.  The standard for 10BASE-T specs unsheilded TW/PR wiring, but most of us
are running at least an overall shielded low loss multipair cable.  What would 
be the best bet for FDDI ( unshielded, overall shield, or individual pairs 
shielded)?
3.  Is it possible to run a multi-pair cable to the office (say 4 pair) and 
transmit two FDDI SAS circuits in one cable bundle (two separate Duplex links)?
We currently do this with Ethernet, run 4 pair overall shielded cable that 
will support two ethernets connections in one cable.
4.  Could one run a multipair cable and run Ethernet on two of the pairs of wires,
and run FDDI SAS on the other two pairs of wires (total of 4 pairs)?  How about
running a DAS over a 4 pair cable???
5.  What would be a safe bet to install that might have a chance of being 
supported and provide the most flexibility, even if it was slightly more expensive?

Any opinions or innovative ideas that you have implemented or contacts that we 
could investigate would be most helpful.  Thanks in advance for your help, and 
response through email would be the quickest and most efficient.


                 ****************************
                 *     Marty J Peterson     *
                 * Battelle Pacific NW labs *
                 *     PO Box 999  K1-87    *
                 *    Richland, WA   99352  *
                 *       (509)375-2693      * 
                 *    mj_peterson@pnl.gov   *
                 *           ^*^            *
                 *           \-/            *
                 ****************************
From: rasp@xlnt.com (Ron Perloff)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: SMT Standard
Date: 13 Apr 92 22:08:15 GMT
Article-I.D.: xlnt.1004
Organization: xdi

In article <1992Apr9.132017.3551@doug.cae.wisc.edu> wittmann@engr.wisc.edu (art
wittmann) writes:

>So what does this mean for Joe Average NetManager?  Should one wait for 7.X
>complient adaptors, hubs & routers?

No need to wait. There are lots of people happily operating FDDI networks
using version 6.2 of the draft SMT standard. Version 7.x cleans up some
broken items and adds enhancements a lot of folks felt were necessary.
I suggest you determine the upgrade policy of the vendors of each piece
of equipment you buy because everyone will change to the version that
ultimately becomes the standard.

>Is SMT typically implemented in 
>firmware/software or in hardware?

Mostly software. Chip sets from various vendors offer some
support, but the vast bulk is in firmware/software.

>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? In the case of routers & hubs, can
>any similar statements be made?

FDDI very carefully defines a "Station" as a thing that attaches to an
FDDI ring either directly as a Dual Attachment Station (DAS) or through a
concentrator as a Single Attachment Station. Yes, there are some other
configurations including Dual MAC-Dual Attachment Stations and
concentrators of all sorts, but these are not germaine to the discussion.

An FDDI to FDDI bridge or router usually contains as many Stations as the
number of FDDI rings to which it attaches. Similarly, a supercomputer
that attaches to 4 FDDI rings to "stripe" data represents 4 FDDI Stations.

Each FDDI Station must have its own LOGICAL SMT entity. Those logical
SMT entities may be either separate executables or multiple invocations
of a single executable at the implementor's discretion.

Most of our clients do not run SMT on the host. The Connection
Management (CMT) protocol within SMT places some responsiveness
constraints with which most people do not like to burden a host.
Further, those selling board level products often like to make those
products as self contained as possible.

ron

Ronald S. Perloff     rasp@xlnt.com
XLNT Designs, Inc. (XDI)
15050 Avenue of Science
Suite 106
San Diego, CA  92128

619 487 9320   -   FAX: 619 497 9768
From: stsai@acsu.buffalo.edu (Shuoh-Ren Tsai)
Newsgroups: comp.dcom.lans.fddi
Subject: Real-Time protocol
Date: 10 Apr 92 23:43:53 GMT
Organization: State Univ. of New York at Buffalo, Dept. of ECE

Hi friends,

   Is there anyone who works on Real-Time Protocol ( the transmission delay
is limited )? I try to design one for Photonics Network.
   If yes, would you send me email?

- Steve Tsai
Xref: sparky comp.dcom.lans.fddi:230 comp.protocols.tcp-ip:2514
From: ddb0248@mcnews.mcdata.com (David Beal)
Newsgroups: comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject: ARP over FDDI and "canonical bit order"
Date: 14 Apr 92 19:34:59 GMT
Organization: McDATA Corp.

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."

The origin of this requirement is presumably the fact that on FDDI,
bytes are transmitted msb first, while on ethernet, they're transmitted
lsb first, plus the fact that the IEEE inexplicably chose to assign
MAC addresses by saying "this is the first bit transmitted", rather
than saying "this is the most significant bit".

I understand that following the above rule should make a FDDI host 
work with a host on a bridged ethernet, because when forwarding
a frame between the dissimilar media, the bridge would maintain *bit
transmission order* on the MAC destination and source addresses,
but would maintain *most-significant/least-significant bit order* on
the remainder of the frame.  Therefore, when either of the boxes receives
an ARP request, he would use the canonically ordered source hardware
address as the destination address of his reply.  OK, fine.

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
From: my@laverde.nsc.com (Mike Yip)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: FDDI and ethernet address spaces
Date: 10 Apr 92 19:14:48 GMT
Reply-To: my@laverde.nsc.com
Organization: National Semiconductor Corp.

In article jb7j2v8@sgi.sgi.com, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1992Apr9.045949.28653@berlioz.nsc.com>, my@laverde.nsc.com (Mike Yip) writes:
>> 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.
>
>Are you guys talking about groups of addresses or addresses with the group
>bit set?
No, that was not me.  ;-)

>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.

>>  ...[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.  ;)


---
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 
| Of course, this is my own opinion!
From: koning@koning.enet.dec.com (Paul Koning)
Subject: Re: FDDI Concentrator Performance
Reply-To: koning@koning.enet.dec.com
Organization: Digital Equipment Co., distributed systems architecture
Date: Thu, 16 Apr 1992 15:09:28 GMT


In article <1992Apr15.195223.15432@kakwa.ucs.ualberta.ca>, Rolly_Noel@quick.ucs.ualberta.ca (Rolly Noel) writes:
|>We are planning to install an FDDI campus backbone that will grow to perhaps
|>8 concentrators and 40 routers over the next 2 or 3 years. The concentrators 
|>will be on a dual ring and the routers will be single attached off the
|>concentrators.
|>
|>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?

Far out.

All concentrators have the same performance.  That's because they basically
just repeat the bits -- each bit going in also goes out.  Exactly as with
Ethernet repeaters, there is no such thing as a "slow" concentrator.

	paul

Xref: sparky comp.dcom.lans.fddi:221 alt.security:2749
From: atkinson@itd.nrl.navy.mil (Ran Atkinson)
Newsgroups: comp.dcom.lans.fddi,alt.security
Subject: Re: FDDI SMT Standard
Date: 11 Apr 92 16:30:13 GMT
Distribution: usa
Organization: Naval Research Laboratory, DC

In article <jc0ae0c@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>Be glad there is a permanent out for the parameter set's, "authentication
>denied", because the set's include goodies useful to Joe College such as
>broadcast packets saying "turn off".  Last I looked, the authentication/
>authorization section of the standard was still a bad joke of a
>to-be-determind hole.  There was no conception of the difference between
>"authorization" and "authentication" among many (probably most) members of
>X3T9.5.  Few seemed to have any idea of the utility and prevalence to Joe
>College of things like etherfind, tcpdump, and netsnoop.

  Vernon's comments are entirely correct.  Much of what is in SMT
desperately needs at least authentication & authorisation controls in
order to preclude really trivial attacks on FDDI based networks.  In
fairness though, FDDI's protocols are not unique in ignoring the
security aspects.  Ethernet, Token -Ring, SONET, ATM, and many more
have also ignored the security aspects.  Heck, we don't even have
authentication in IP or ICMP or TCP...

  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.  SMT also adds some nice new covert channels,
so it might be proportionately worse.  I haven't seen any detailed
numbers on this (if you have seen such things, please email with a
reference to the article or book) but my very rough back of the
envelope calculations make me think it would be hard to get stock FDDI
through a TNI (Red Book) evaluation [has ANY computer system, as
distinguished from a networking-only product like Verdix or Boeing,
ever actually gone through a TNI formal evaluation ?] .

Ran
atkinson@itd.nrl.navy.mil
Xref: sparky comp.dcom.lans.fddi:195 comp.dcom.lans:1712 comp.dcom.lans.ethernet:544 comp.dcom.lans.misc:195
From: koning@koning.enet.dec.com (Paul Koning)
Newsgroups: comp.dcom.lans.fddi,comp.dcom.lans,comp.dcom.lans.ethernet,comp.dcom.lans.misc
Subject: Re: Single mode to multimode Converters
Date: 6 Apr 92 14:25:06 GMT
Reply-To: koning@koning.enet.dec.com
Followup-To: comp.dcom.lans.fddi
Organization: Digital Equipment Co., distributed systems architecture


In article <1992Apr2.203117.15527@alw.nih.gov>, brunetti@alw.nih.gov (Jim Brunetti) writes:
|>On the NIH campus, we have both single mode and multimode fiber in our physical plant.  We would like to utilize the single mode fiber to extend our existing FDDI backbone.  (We are not able to put any more multimode into the ground anytime soon.)  We are currently evaluating single-mode to multimode converters and would appreciate any pointers to technical papers, journal articles, personal experiences or even (gasp!) vendor literature. 
|>    
|>
|>
|>jim brunetti       brunetti@alw.nih.gov
|>
|>"The game's the thing"
|>
|>________________________________________________________________

I'd suggest instead you use FDDI hardware with single mode PMDs.  That way
you will be assured that the single mode transceivers obey all the FDDI
requirements, which is a guarantee you would NOT necessarily get with an
outboard converter.  In addition (though it may not matter in your case)
you would be able to go a greater distance with the on-board single mode
PMDs than with the converters, since you eliminate extra steps that introduce
jitter and thus limit your distance.

	paul
From: my@laverde.nsc.com (Mike Yip)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: SMT Standard
Date: 11 Apr 92 00:58:16 GMT
Reply-To: my@laverde.nsc.com
Organization: National Semiconductor Corp.

>So what does this mean for Joe Average NetManager?  Should one wait for 7.X
>complient adaptors, hubs & routers?  ...

No, just go ahead and use the current FDDI product.  ;-)

> ... Is SMT typically implemented in firmware/software or in hardware?

Most of the current implementation of SMT are implemented on firmware/software.
A small part of the CMT portion of SMT might be implemented in chip.
[ to me firmware = software running on a dedicated uP for networking/FDDI,
  and software   = device driver running on the main CPU.  ]


> ... 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.  Companies like
XDI can probably give you a better answer [Bob Grow are you there?].  
SMT can be implemented as a driver, in PROM, in chips ...  Depends on your system
will probably need to upgrade a program or device driver or replace a PROM.
That should not be too hard, right?


>In the case of routers & hubs, can any similar statements be made?
Same.


>So many questions, so little knowledge (on my part).
So much knowledge, but even more problems ....  ;-)

---
| 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: tjet@upas.IFA.Hawaii.Edu (Tjet Sun)
Subject: Re: Single mode to multimode Converters
Reply-To: tjet@upas.ifa.hawaii.edu
Organization: IFA, Univ. of Hawaii
Date: Mon, 6 Apr 1992 21:20:31 GMT


In article <34966@nntpd.lkg.dec.com>, koning@koning.enet.dec.com (Paul
Koning) writes:
> 
> 
> I'd suggest instead you use FDDI hardware with single mode PMDs.  That way
> you will be assured that the single mode transceivers obey all the FDDI
> requirements, which is a guarantee you would NOT necessarily get with an
> outboard converter.  In addition (though it may not matter in your case)
> you would be able to go a greater distance with the on-board single mode
> PMDs than with the converters, since you eliminate extra steps that introduce
> jitter and thus limit your distance.
> 
> 	paul
> 

  When we were in the market, those PMDs were not yet available.  Even
now they are slow in coming out and not cheap either.  (What makes
them so much more expensive?)  Anyway we actually went with
ADC/Fibermux and they seem to perform quite well once things settled.

  My question is, is there a standard for SM FDDI yet?  Can I mix and
match SM PMDs for different equipment manufacturers?

  Thanks in advance.

  Tjet


==============================================================================
Tjet Sun, Institute for Astronomy, 2680 Woodlawn Drive, Honolulu, Hawaii 96822
Internet: tjet@upas.ifa.hawaii.edu                   Bitnet: tjet@uhifa.bitnet
Voice: (808) 956-8718                                      Fax: (808) 988-2790
==============================================================================
From: larry@xlnt.com (Larry Pollack)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: FDDI Concentrator Performance
Date: 16 Apr 92 20:37:07 GMT
Reply-To: larry@xlnt.com
Organization: XLNT Designs, Inc.

In article <jjvkg1s@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> In article <1992Apr15.195223.15432@kakwa.ucs.ualberta.ca>, Rolly_Noel@quick.ucs.ualberta.ca (Rolly Noel) writes:
|> > We are planning to install an FDDI campus backbone that will grow to perhaps
|> > 8 concentrators and 40 routers over the next 2 or 3 years. The concentrators 
|> > will be on a dual ring and the routers will be single attached off the
|> > concentrators.
|> > 
|> > 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?
|> 
|> 
|> Yes, please let all of us know which concentrator can do only 80% of full
|> speed.  Such a thing would would be non-conforming junk.  FDDI
|> concentrators are supposed do nothing to the bits passing through them.
|> They can neither filter nor otherwise improve them, contrary to statements
|> from some concentrator sales slime.
|> 
|> 
|> An FDDI router or bridge that could handle 80Mbit/sec could be either a
|> slow machine (e.g. if routing 4500 byte frames between two FDDI rings)
|> or a very fast machine (e.g. if forwarding minimum size frames from
|> thousands of stations).
|> 
|> 
|> Vernon Schryver,  vjs@sgi.com

Perhaps this vendor is comparing apples to concentrators. As Vernon states, a
straight concentrator should not have any effect on data passing through (except
a little extra latency on the ring). A concentrator primarly provides access for
single attachment devices to the dual ring. It has no data processing function.

However, vendors are now providing FDDI hubs with concentrator capabilities. 
Theses boxes have the basic attachment and master ports needed by an FDDI
concentrator. In addition to the concentrator capability, they may also have one
or more of the following: bridge, router, SNMP agent, SNMP proxy agent, WAN
interfaces, etc. This may be what the vendor was referring to. Make sure you are
looking at the same functionality when comparing two units.

--
/======================================================================\
| Lawrence J. Pollack                   | Your source for FDDI SMT.    |
| XLNT Designs, Inc.                    | Voice   : 619-487-9320       |
| Internet: larry@xlnt.com              | Fax     : 619-487-9768       |
\======================================================================/
From: shah@brahms.amd.com (Amit Shah)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Daisy chaining SAS FDDI workstations
Date: 8 Apr 92 21:01:00 GMT
Organization: Advanced Micro Devices; Sunnyvale, CA

In article <j9dqmr8@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>Actually, running without PCM is a lot simpler than running with PCM.  You
>just put your MAC into the ring whenever you're ready, and bypass yourself
>the rest of the time, either with an optical bypass or electrically (e.g.
>PHY repeat-mode).  It is only a little tricky to put a "class C" station
>into a ring between a pair of DAS's doing PCM.  That trickiness also is a
>lot easier than actually implementing PCM.  All you do is put your MAC into
>the ring when you're ready and the incoming line state is ILS or ALS, and
>supidly repeat all other lines states.  Unless the neighbors note PDU's
>during LCT, they'll never know the difference, except that the upstream
>neighbor's NSA frames will not make sense.


Not as simple as it sounds. 


>For those to whom that paragraph doesn't make sense:  the SMT standard,
>including PCM, made FDDI vastly more complicated.


Why do I get the impression that you hate the SMT document????

>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.

--
Amit Shah
Sys. Engg. & Prod. Planning Engineer		Ph.:(408)987 2479
Optical Networks Engineering			Fax:(408)987 2814
901 Thompson Place, M/S 70			email:amit.shah@amd.com