HDTenEightyP/NetNews huggingface dataset:
From: my@dunkin.nsc.com (Mike Yip)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: FDDI standards
Date: 19 Nov 92 19:19:05 GMT
Reply-To: my@dunkin.nsc.com
Organization: National Semiconductor Corp.

In article dvlqcxh@lynx.unm.edu, lriffe@isis.unm.edu (Larry Riffe II) writes:
>
>   I was wondering if anybody could tell me what the most current
>   revision of the following FDDI standards was and where I might
>   be able to get them.  Also if anybody knows if work is currently
>   going on, on the standards and a new revision will be released
>   soon (ie, the next six months), I would appreciate that information
>   as well.

Looking at the documents on my desk (meaning I am not sure if it is
the absolute latest doc).

Document	Current			Furture
SMT		7.2 June 25, 1892	None (See SMT-2)
SMT-2(?)	0.01 Oct 1892 -- This is a working copy, not a standard or even draft
HRC		6.3 May 28, 1892
PHY-2		5.0 June 17, 1892

;)

---
| 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: lriffe@isis.unm.edu (Larry Riffe II)
Subject: FDDI standards
Date: Wed, 18 Nov 92 21:51:16 GMT
Organization: University of New Mexico, Albuquerque
Keywords: FDDI standards MAC PHY PMD SMT HRC SMF-PMD


   I was wondering if anybody could tell me what the most current
   revision of the following FDDI standards was and where I might
   be able to get them.  Also if anybody knows if work is currently
   going on, on the standards and a new revision will be released
   soon (ie, the next six months), I would appreciate that information
   as well.

             MAC                PHY
             PMD                SMT
             HRC                SMF-PMD


					Thanks,
						Larry G. Riffe II
						lriffe@ariel.unm.edu


Newsgroups: comp.dcom.lans.fddi
From: koning@koning.enet.dec.com (Paul Koning)
Subject: Re: SAS Rings
Keywords: SAS Concentrators
Reply-To: koning@koning.enet.dec.com
Organization: Digital Equipment Co., distributed systems architecture
Date: Tue, 17 Nov 1992 22:13:17 GMT


In article <1992Nov17.191249.21391@den.mmc.com>, geger@phantom.den.mmc.com (George Eger (303) 971-6974) writes:
|>Is there a particular reason why SAS rings of more than 2 stations are not
|>allowed by SMT?  Is this just a ploy to sell more hardware?  Seems to me
|>there are good system configurations that could warrant SAS rings (like a
|>bunch of equipment all in one rack/room that doesn't need the complication
|>of DAS or concentrators).
|>
|>Comments?
|>
|>GWE
|>
|>||==========================================================================
|>||George Eger                  ||   Voice - (303) - 971 - 6974            ||
|>...

Simple... PCM (the initialization protocol SMT runs between two ports) is
a two-party protocol.  It would have to be DRASTICALLY different to be
an N-party protocol, which is what you need to initialize the sort of
topology you mentioned.  Actually, it's not clear that such a protocol
could even be designed.

People have experimented with these topologies, typically by not running
any startup protocol at all but simply putting everything into active
state right away.  With some luck that may work often enough to be 
useful in experiments...

	paul
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Questions on implementing 65 node network
Keywords: FDDI, Sun
Date: 20 Nov 92 21:49:54 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1ejbadINNl57@early-bird.think.com>, sid@think.com (Sid Stuart) writes:
> 
> We are currently considering moving our backbone network from
> Ethernet to FDDI. As part of this change, we would also move
> additional computers onto the backbone. The resulting network
> would consist of three or four SGI's, 5-10 CM5's and 50 Sparc
> based computers: about 30 Sun 4/65's and 4/75's acting as
> fileservers and about 30 Sun 10/30's, 10/40's and 4/75's
> acting as compute servers.  The network would span two
> buildings and be about 1500-2000 meters in length. I expect
> the network to see 20-30 mbits of traffic during the day. 
> 
> Has anyone implemented such a network? What kind of problems have
> you seen? What are the performance characteristics? What kind of
> latency can I expect to see between stations under a load of 20-30
> mbits? Am I trying to put too much equipment on too large of a
> network or can FDDI deal with this distance/load?


The standard says you can have 2 kilometers between stations.  You can
probably cheat to get above 2000 m to deal with your buildings 2000 m
separation.

Are you going to put all 70 computers directly on the FDDI dual-ring?
With no concetrators?

If so, I would expect the ring to have a ring latency around 85
microseconds when the ring is THRU and around twice that when WRAPped.
Assuming all of the stations are doing ordinary TCP, UDP, and NFS kinds
of things, the average token latency of a ring at 30Mbit/sec or 30%
load and 100 usec latency is around 150 microseconds.   (The idea is
that in a 1 second, the ring will spend 300 milliseconds moving data
and the rest of the time spinning the token.  So solve for the number
of times the token will spin during the 700 milliseconds of idle time.)

At 30% load with ordinary stuff, any station will be able to transmit
any time a token comes around.  Thus, the network latency attributable
to FDDI in this situation averages 150 microseconds.

If you use concentrators, add around 1 microsecond per port on each
concentrator, whether active or not, to the ring latency, and recompute
the token latency.

You can get a lot more than 30 Mbit/sec TCP/IP/FDDI out of such a ring,
depending on the stations.

I know of FDDI networks like the one described, although they tend to
have more SGI, DEC or IBM boxes and fewer Sun boxes.

(If "20-30 mbits of traffic during the day" means 30 Mbit/day, then for
heaven's sake do NOT waste money on FDDI.  Use ethernets or T1 or even
56K lines.)


Vernon Schryver,  vjs@sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Minimal MAC/LLC
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 18 Nov 1992 16:43:36 GMT

In article <GAH.92Nov18150548@HP370T.trc.mew.mei.co.jp>, gah@trc.mew.mei.co.jp (Gary A. Hildebrand) writes:
> 
> Let's imagine a hypothetical case.  You want to implement minimal data
> transport over FDDI, with just enough MAC/SMT support for somewhat robust
> LLC, and nothing more.  You don't care about MIB management or SRF's at
> this point.  Anyone who's read through the FDDI standards can tell you what
> is perscribed as mandatory and what is optional, but how much can you
> really get away with?  In a real implementation, are any SMT frame services
> absolutely essential for keeping the ring up?  NIF frames immediately come
> to mind.  What about the many different types of CMT services and
> functions?  I would suppose that most nodes would cause trouble if they
> didn't all implement full RMT and PCM support in or out of the MAC
> chip/software layer.

All you need to play with other standard-conforming FDDI stations
and concentrators is CMT signalling.  You need none of the frame
management stuff including NIF's.  The ring will work just fine even
if other stations' ring maps are bogus.

By "play", I mean just that.  You can't sell a real product that does
not do all of the mandatory stuff in SMT 6.x.  Too many of your biggest
potential customers would run screaming.

> This case is actually not so hypothetical.  I'm wondering about PC FDDI
> interface cards such as the one from Network Periperals.  Does the small
> NDIS driver loaded and/or firmware on the board actually implement all the
> ANSI-draft-standard mandatory components of the MAC/SMT protocols that are
> not covered by the National chipset, or just a bare minimum functional
> subset?  Unfortunately, this board comes with little or no technical
> information.

For many reasons, from the people involved to their evident intention
to make a profitable product to the test beds their systems have been
seen on, I would be very surprised if NPI's products failed to
implement more than just the mandatory part of SMT 6.x or if they do
not soon conform to SMT 7.2.

As you say, there are a lot of messy SMT frames.  I think a case can be
made that handling the SMT frames is about as complicated as doing
TCP/IP.  Fortunately, a straight forward implementation of the
mandatory SMT frames (or of TCP/IP) is not hard, at least for computers
of this decade.  That's shown by the nearly universal support of SNMP
in FDDI concentrators and even ethernet twisted pair hubs.

Ironically, some in ANSI X3T9.5 justified much of the SMT frame based
stuff on the grounds that most stations and concentrators could not
afford TCP or TP4 stacks and so could not use SNMP or CMOT.  The
company that pushed that view hardest was in the business of selling
SMT implementations to other vendors.  Most ironically, that company
was soon seen at test beds with SNMP managed products.


Vernon Schryver,  vjs@sgi.com
From: my@berlioz.nsc.com (Mike Yip)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Minimal MAC/LLC
Summary: Why do SMT Frame Based management?
Date: 19 Nov 92 16:45:06 GMT
Organization: National Semiconductor Corp.

In article vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>Ironically, some in ANSI X3T9.5 justified much of the SMT frame based
>stuff on the grounds that most stations and concentrators could not
>afford TCP or TP4 stacks and so could not use SNMP or CMOT.  The
>company that pushed that view hardest was in the business of selling
>SMT implementations to other vendors.  Most ironically, that company
>was soon seen at test beds with SNMP managed products.

One argument that ANSI committee brought up was that they "needed"
management for FDDI ring and no one could decide that if a station
would implement SNMP or CMOT or both.  Therefore, SMT frames are 
"needed".  But then again, if the network manager did not brother to
install SNMP for network management, then he probably didn't care
about management or did not know about it.  So ... what good is to 
having SMT frames running around?  Well you can get a pretty ring map.

-- 
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 
| Of course, this is my own opinion!
From: bob (Bob Grow)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: SMT operation that can bring ring down
Date: 16 Nov 92 20:23:11 GMT
Article-I.D.: xlnt.1249
Organization: xdi

In article <1992Nov12.184036.16534@octel.com> pfloyd@octel.com (Michael
Barnett) writes:
>
>I'm having some trouble with a wrapped ring that goes down for
>exactly 10 seconds occassionaly.  Actually, one station out of
>3 sees the ring go down for 10 seconds.  We're using the AMD
>supernet chip set and synernetics SMT.  Is there any test that
>the SMT may be running that is causing the ring to go down? (e.g.
>trace function, path test, etc.)  I've looked through the specs
>but can't find anything that has this long of a time frame.
>I suspect that it may have something to do with the LEM since
>we're getting alot of lost frame hits due to a bug within the
>chipset.  Any help would be GREATLY appreciated.
>
>
>                        - Mike
>-- 
>--
>pfloyd@octel.com
>

A little more topology information would have been helpful. I assume that 
this ring is as shown below. With stations A and C in WRAP.

+-----+ pri +-----+     +-----+
|     |---->|     |---->|     |
|  A  | sec |  B  |     |  C  |
|     |<----|     |<----|     |
+-----+     +-----+     +-----+

If only one of the three stations is losing ring operational for an 
extended time, then it is possible that it is an LEM condition. To verify 
this you need to examine CF-State. 

Look at the problem and neighbor station to see if configurations are 
changing. For example if the problem station is C then C would be changing 
from WRAP A to ISOLATED and the neighbor station (B) would be going from 
THRU to WRAP A. If the problem station is B then it would be going from 
THRU to WRAP A or WRAP B and the corresponding neighbor would go from WRAP 
to ISOLATED.

If the problem station is connected to a concentrator instead of as 
illustrated above then it would go from WRAP to ISOLATED and the 
concentrator is staying in the same CF-State though is still reported 
(e.g., THRU to THRU) as the master port is included and excluded from the 
ring.

Exactly ten seconds is unusual because it is closer to the trace timeout 
(defaults produce timeouts of 9 seconds) than to the link confidence test 
time (default 5 seconds after LEM reject). But in the trace situation, the 
ring would be non operational for all three stations for for at least the
timeout times. In LEM reject, the bad link would be removed from the ring, 
and included after passing LCT. Perhaps in your samples of the problem, it 
passed LCT on its second attempt or LCT_long was set to 10 seconds.

It's tough to debug a problem with as little information as you have given. 
I hope this will be helpful.


Bob Grow  (bob@xlnt.com)

XLNT Designs, Inc., 15050 Avenue of Science, STE 106, San Diego, CA 92128
Voice: 619-487-9320    Fax: 619-487-9768
Newsgroups: comp.dcom.lans.fddi
From: geger@phantom.den.mmc.com (George Eger (303) 971-6974)
Subject: SAS Rings
Keywords: SAS Concentrators
Organization: Martin Marietta Astronautics Group
Date: Tue, 17 Nov 1992 19:12:49 GMT


Is there a particular reason why SAS rings of more than 2 stations are not
allowed by SMT?  Is this just a ploy to sell more hardware?  Seems to me
there are good system configurations that could warrant SAS rings (like a
bunch of equipment all in one rack/room that doesn't need the complication
of DAS or concentrators).

Comments?

GWE

||==========================================================================
||George Eger                  ||   Voice - (303) - 971 - 6974            ||
||Fault Tolerant Avionics      ||   Fax   - (303) - 977 - 1145            ||
||Launch Systems               ||   MS T320                               ||
||Martin Marietta Astro Group  ||   P.O. Box 179, Denver CO 80201         ||
||==========================================================================
||We are at a cusp - between the past when humans were more reliable than ||
||computers and the future when computers are more reliable than humans.  ||
||==========================================================================
||All opinions (however truthful or misinformed) are my own.              ||
||==========================================================================
Newsgroups: comp.dcom.lans.fddi
From: koning@koning.enet.dec.com (Paul Koning)
Subject: Re: Minimal MAC/LLC
Reply-To: koning@koning.enet.dec.com
Organization: Digital Equipment Co., distributed systems architecture
Date: Wed, 18 Nov 1992 15:19:54 GMT


In article <GAH.92Nov18150548@HP370T.trc.mew.mei.co.jp>, gah@trc.mew.mei.co.jp (Gary A. Hildebrand) writes:
|>All,
|>
|>Let's imagine a hypothetical case.  You want to implement minimal data
|>transport over FDDI, with just enough MAC/SMT support for somewhat robust
|>LLC, and nothing more.  You don't care about MIB management or SRF's at
|>this point.  Anyone who's read through the FDDI standards can tell you what
|>is perscribed as mandatory and what is optional, but how much can you
|>really get away with?  In a real implementation, are any SMT frame services
|>absolutely essential for keeping the ring up?  NIF frames immediately come
|>to mind.  What about the many different types of CMT services and
|>functions?  I would suppose that most nodes would cause trouble if they
|>didn't all implement full RMT and PCM support in or out of the MAC
|>chip/software layer.

If you don't care about standards conformance, and your network is small
enough that you don't feel a need to worry about some of the fancier
fault recovery mechanism, you could cut quite a lot.  You need MAC, PHY,
and PMD as specified, of course.  In SMT, you need very little.  PCM is
necessary, because that's how you talk your neighbor into letting you join
the ring.

However, your node and the ring will work just fine (in the sense of allowing
user data traffic to proceed -- though NOT in the sense of being manageable)
without ANY SMT frames at all.  Of course, you can't get a ring map, not
even from fully conforming stations, unless you at least do NIF by the rules.
And so it goes in general ... the more of the required parts are in fact
present, the more your node resembles a normal, fully manageable, FDDI node.

|>This case is actually not so hypothetical.  I'm wondering about PC FDDI
|>interface cards such as the one from Network Periperals.  Does the small
|>NDIS driver loaded and/or firmware on the board actually implement all the
|>ANSI-draft-standard mandatory components of the MAC/SMT protocols that are
|>not covered by the National chipset, or just a bare minimum functional
|>subset?  Unfortunately, this board comes with little or no technical
|>information.

I don't know about that PC card.  But there is at least one (the DEC one)
where the SMT support is done entirely by firmware (in a 68000) on the
adapter itself.

|>Gary Hildebrand

	paul koning
From: my@dunkin.nsc.com (Mike Yip)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: SAS Rings
Date: 19 Nov 92 07:14:27 GMT
Reply-To: my@dunkin.nsc.com
Organization: National Semiconductor Corp.

In article koning@koning.enet.dec.com (Paul Koning) writes:
>Simple... PCM (the initialization protocol SMT runs between two ports) is
>a two-party protocol.  It would have to be DRASTICALLY different to be
>an N-party protocol, which is what you need to initialize the sort of
>topology you mentioned.  Actually, it's not clear that such a protocol
>could even be designed.
>
>People have experimented with these topologies, typically by not running
>any startup protocol at all but simply putting everything into active
>state right away.  With some luck that may work often enough to be 
>useful in experiments...

Hi Paul.  What's up?  In FDDI-2/SMT-2, people are talking a simplex 
protocol designed to connect SAS together like a bus.  The protocol calls
for a bypass (most likely electrical, to be used with TP-FDDI, but can 
be optical) for each SAS.  And the simplex PCM is a ONE way, three signal 
protocol (geez, not much of a protocol to it).  

The following is one possible configurations:

	T<=>BP<======>BP<=======>BP<=======>BP<=>T
	    |$        |$         |$         |$
	    |$        |$         |$         |$
	    SAS       SAS                   SAS

BP=Bypass, T=Termination Loop, |$=duplex cable with BP-on/off.

There are other possible configuration which connects to a concentrator
which supports simplex operation also.  The Oct 1992 X3T9.5 mailing
should show more detail info.  I think that the Simplex operation will be 
added to SMT-1 also.  (But then again, I can speak for the committee.)

---
| 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: davis@realtime.ab.ca (Glenn Davis)
Subject: UB bridge dropping NETBEUI packets
Organization: RealTime Consulting Ltd.
Date: Wed, 18 Nov 1992 18:43:50 GMT

I am having difficuly with an Ungermann Bass fiber bridge.  It seems that
none of the NETBEUI multicast messages are getting across the bridge.  If
anyone has encountered this situation, or has any suggestions I would
appreciate the help.

All other traffic (TCP/IP,DECnet,LAT,...) make it across with no problems,
if the PC make a request using NETBEUI on a specific address it works fine.
The broadcasts from the servers on multicast addresses never reach the
other side of the bridge.

The bridge has a FB5361 card for fiber interface.

Thanks,
Glenn Davis
davis@realtime.ab.ca
From: sid@think.com (Sid Stuart)
Newsgroups: comp.dcom.lans.fddi
Subject: Questions on implementing 65 node network
Date: 20 Nov 1992 18:38:05 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: world
NNTP-Posting-Host: grub.think.com
Keywords: FDDI, Sun


We are currently considering moving our backbone network from
Ethernet to FDDI. As part of this change, we would also move
additional computers onto the backbone. The resulting network
would consist of three or four SGI's, 5-10 CM5's and 50 Sparc
based computers: about 30 Sun 4/65's and 4/75's acting as
fileservers and about 30 Sun 10/30's, 10/40's and 4/75's
acting as compute servers.  The network would span two
buildings and be about 1500-2000 meters in length. I expect
the network to see 20-30 mbits of traffic during the day. 

Has anyone implemented such a network? What kind of problems have
you seen? What are the performance characteristics? What kind of
latency can I expect to see between stations under a load of 20-30
mbits? Am I trying to put too much equipment on too large of a
network or can FDDI deal with this distance/load?

Any advice, opinions or suggestions are welcome,
Sid Stuart
sid@think.com
-- 
Sid Stuart, Thinking Machines Corp.

sid@think.com
{uunet,harvard}!think!sid
Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: SAS Rings
Keywords: SAS Concentrators
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 17 Nov 1992 22:56:51 GMT

In article <1992Nov17.191249.21391@den.mmc.com>, geger@phantom.den.mmc.com (George Eger (303) 971-6974) writes:
> 
> Is there a particular reason why SAS rings of more than 2 stations are not
> allowed by SMT?  Is this just a ploy to sell more hardware?  Seems to me
> there are good system configurations that could warrant SAS rings (like a
> bunch of equipment all in one rack/room that doesn't need the complication
> of DAS or concentrators).
> 
> Comments?


I've played with such variations of FDDI.  They are a royal pain to get
and keep working.  Without CMT signalling, all you know is that the
whole ring is dead.  You don't know which machine is powered off, or
which connector is loose, or whatever.  Or, worse, what combination of
such things is wrong.

The cost of CMT is only about 300 lines of C (ironically about the same
whether you do it all yourself in the host or "node processor" or if
you use one of the fancy PHY chips that claim to do it all for you).
You do need another set of ODL's, which cost <$100/pair.

Much more complication is involved in other parts of FDDI and SMT, with
much lower return on investment, than insisting on a dual ring.

One skary kludge that is effective and cheap is to have a very few
single attach stations lurk in the primary ring between two dual
attached stations.  The single attached stations simply pass symbols
except when the ring is idle or active, and then they look for tokens
and do normal MAC things.  I don't think this kludge is worth the
effort.

If you can afford the other over-designed parts of FDDI, then you can
afford the dual ring.  If you can't, then look into other media.  One
hack I've thought sounds neat and cheap is something I've called
"gatling ethernet."


I think that a the "one rack/room" situation calls for simple
dual-attached stations, without concentrators.


vjs
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell