HDTenEightyP/NetNews huggingface dataset:
From: will@vulcan.austin.ibm.com (Will Fiveash)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Date: 12 Oct 92 18:29:36 GMT
Organization: IBM PSP Austin, Tx.

In article <qq7d1l0@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1992Oct7.150707.29127@awdprime.austin.ibm.com>, will@vulcan.austin.ibm.com (Will Fiveash) writes:
>> In article <qncmi00@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>> >The only IP fragmenting that an FDDI-ether bridge will usually need to
>> >do is of UDP packets.  UDP packets are datagrams, and have no sequence
>> >numbers of any kind.  If you don't have FDDI-ether-FDDI networks, the
>> >initial MSS negotiation in TCP will pick 1500.  This is consistent with
>> >the TCP/IP lore (and RFC) that considers fragmenting harmful.
>> 
>> I am somewhat confused about the statement concerning MSS negotiation.
>> My understanding was that if the two connecting systems were on the
>> same physical network then the MSS was the MTU of the interface -
>> TCP/IP header length.  If they were not on the same physical net, i.e.
>> router(s) involved, then the MSS was 536.  This is what I am reading
>> from Doug Comer's book "Internetworking with TCP/IP".
>
>Are we disagreeing?  I don't think so.
>

You are right.  As I reread the above statements, I see that it is a
FDDI-ether BRIDGE that you were discussing so a TCP connection across
it is transparent as far as the MSS negotiation is concerned.  Given
this, it makes sense that the MSS will be the smaller of the two i.e.
1500 in this case.

Thanks for the info.

>Vernon Schryver,  vjs@sgi.com


-- 
Will Fiveash,  "My opinions above, facts below."
Internet:  will@austin.ibm.com 
Newsgroups: comp.dcom.lans.fddi
From: merike@alw.nih.gov (Merike Kaeo)
Subject: void frames 
Keywords: void
Organization: National Inst. of Health, DCRT, CSL
Date: Wed, 7 Oct 1992 14:58:53 GMT

Am testing some equipment and on occasion see some void
frames with SRC=DST=0.  To my understanding this is a 
bogus frame.  Also, from what I understand, void frames 
have data length of zero whereas these particular voids
have varying sizes - up to max fddi length.  Any clue as
to how I can track down who is doing this (other than
disconnecting stations one-by-one) ?

-- 

Merike Kaeo			merike@alw.nih.gov
National Institutes of Health	(301) 402-1548 


                          o
                            \
                          \0/
       ||==================|=====||
       ||-+-+-+-+-+-+-+-+-/\+-+-+||
       ||=================\=\====||
       ||                        ||
       ||                        ||
       ||                        ||

    ......kill or be killed.....
From: mjohnson@cs.ucsd.edu (Michael Johnson)
Newsgroups: comp.dcom.lans.fddi
Subject: FDDI Synchronous Bandwidth Allocation.
Summary: how does the SMT allocate asych. bandwidth?
Date: 12 Oct 92 18:55:36 GMT
Organization: =CSE Dept., U.C. San Diego


Greetings.  I am interested in better understanding
the method by which individual stations bid, reserve,
and relinquish available synchronous bandwidth.  The
American Nation Standard MAC document states only that
each station initially has a zero synchronous bandwidth
allocation, and that an SMT protocol is used to change
this allocation.  Is this allocation protocol unspecified,
and therefore left to implementation?

Though I have a copy of the draft proposed standard,
SMT ASC X3T9.5 Rev. 6.2 (May 1990), I have been unable
to find an explicit reference to the MAC described
protocol.

Your help and/or references are greatly appreciated.
-Michael Johnson

Newsgroups: comp.dcom.lans.fddi
From: merike@alw.nih.gov (Merike Kaeo)
Subject: resolving claims
Keywords: claim
Organization: National Inst. of Health, DCRT, CSL
Date: Wed, 7 Oct 1992 15:42:28 GMT

Resolving spurious claims in a multivendor environment
is rather difficult at this point.  I've noticed that
some vendors have a variable which lets you see how
many times a particular device initiated a claim process.
(some even tell you how many times it received higher /
lower claim bids).  This would seem helpful if all
vendors implemented this. 
 
-- 

Merike Kaeo			merike@alw.nih.gov
National Institutes of Health	(301) 402-1548 


                          o
                            \
                          \0/
       ||==================|=====||
       ||-+-+-+-+-+-+-+-+-/\+-+-+||
       ||=================\=\====||
       ||                        ||
       ||                        ||
       ||                        ||

    ......kill or be killed.....
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: void frames
Keywords: void
Date: 7 Oct 92 17:34:26 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Oct7.145853.28738@alw.nih.gov>, merike@alw.nih.gov (Merike Kaeo) writes:
> Am testing some equipment and on occasion see some void
> frames with SRC=DST=0.  To my understanding this is a 
> bogus frame.  Also, from what I understand, void frames 
> have data length of zero whereas these particular voids
> have varying sizes - up to max fddi length.  Any clue as
> to how I can track down who is doing this (other than
> disconnecting stations one-by-one) ?


I do not think there is any rule or even suggestion that void frames
have zero INFO bytes.  They can be any length that you need them to
be.  I seem to recall one router that liked occassional 40 byte voids.
I have used infrequent 107 byte voids in one FDDI implementation to
measure the ring latency.  107 was just big enough to let the node
processor get ready to receive it after sending it, making the
measurement more accurate; the exercise either produced a good value
or no value at all.

SRC=0 does seem bogus, unless you have a station with a MAC address of 0,
which itself would be bogus, provide the address is a long, 48-bit
address.  Nothing should strip the frame unless it recognizes its
source address.  (Such an orphan frame will eventually meet the same
fate as a fragment when it runs into a MAC that is transmitting.)


Vernon Schryver,  vjs@sgi.com
From: roger@elvis.NoSubdomain.NoDomain (Roger Moyers)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Is dual homing easy?
Date: 13 Oct 92 20:18:55 GMT

In article <r0d0lgk@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|> As Paul wrote, the concentrators do not have to support "dual homing".
|> A concentrator cannot tell if the host is dual homed or note.

However concentrators should be capable of dual homing on their own attachment
phys.

-- 
--- Roger Moyers
--- XLNT Designs Inc. (XDI)
--- 15050 Avenue of Science  Suite 106
--- San Diego,  CA  92128  USA
--- Voice: (619)487-9320  Fax: (619)487-6798  email: roger@xlnt.com
From: will@vulcan.austin.ibm.com (Will Fiveash)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Date: 7 Oct 92 15:07:07 GMT
Organization: IBM PSP Austin, Tx.

In article <qncmi00@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>The only IP fragmenting that an FDDI-ether bridge will usually need to
>do is of UDP packets.  UDP packets are datagrams, and have no sequence
>numbers of any kind.  If you don't have FDDI-ether-FDDI networks, the
>initial MSS negotiation in TCP will pick 1500.  This is consistent with
>the TCP/IP lore (and RFC) that considers fragmenting harmful.

I am somewhat confused about the statement concerning MSS negotiation.
My understanding was that if the two connecting systems were on the
same physical network then the MSS was the MTU of the interface -
TCP/IP header length.  If they were not on the same physical net, i.e.
router(s) involved, then the MSS was 536.  This is what I am reading
from Doug Comer's book "Internetworking with TCP/IP".

>Vernon Schryver,  vjs@sgi.com


-- 
Will Fiveash,  "My opinions above, facts below."
Internet:  will@austin.ibm.com 
Newsgroups: comp.dcom.lans.fddi
From: scornd5@solomon.technet.sg (Ng Wee Teck)
Subject: Promiscuous Mode on FDDI?
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Fri, 16 Oct 1992 07:15:17 GMT

I would appreciate help on the following:

a.	Does FDDI support promiscuous mode as in ethernet?  

b.	The platform we're interested in is HP9000/s720 workstation
EISA FDDI adaptor.  How difficult is it to program the workstation such
that it can monitor all packets on the network?  

c.	Are there any FDDI concentrator device in the market that can
do traffic filtering?  We're interested in concentrator that offers
similar security functionalities as Synoptics Secure Hub.

d.	Can other vendors' FDDI cards support promiscuous monitoring?

regards. 
Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Is dual homing easy?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 12 Oct 1992 16:02:50 GMT

In article <1992Oct12.060447.1035@anza.3com.com>, root@anza.3com.com (Operator) writes:
> DART@SLACVM.SLAC.STANFORD.EDU (415) writes:
> Exactly as you expected. The DAS can be connected as a SAS with a
> backup link to the second concentrator. This mean your server 1 is
> single attached to the ring at anytime. Also I presume your
> concentrator and your DAS server interface are all supporting Dual
> homing.


As Paul wrote, the concentrators do not have to support "dual homing".
A concentrator cannot tell if the host is dual homed or note.

How can a compliant DAS station not support dual homing?  I think even
back to SMT-6.2 dual homing was implicitly present.

Note that some of us have had bugs in our DAS stations with respect to
switching between A and B ports, and so were not entirely compliant.
(The polite will not ask me for a list of vendors with such bugs.
Besides, by Interop91 they were fixed.)


Vernon Schryver,  vjs@sgi.com
From: rasp@xlnt.com (Ron Perloff)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Dual Homing II
Date: 14 Oct 92 16:37:24 GMT
Organization: xdi

In article <40056@fibercom.COM> mack@frugal.fibercom.com (Richard Mack) writes:

>Could you please post the situation where a port could pass LCT and not pass
>packets? The only thing I can envision would be if the PH_DATA.(request||data)
>lines in the concentrator are broken, but the station self-test should be
>able to find that.

Here are a two others:

1. LCT is a PHY level test. It does not address the MAC's ability
to move frames. It is conceivable that, in between the time since
the DAS node performs its self test before applying for entry
to the ring at either concentrator and the time when a link
to one concentrator fails and it has to connect through the other,
the DAS no longer has a good connection between the MAC and the PHY.

2. LCT exercises the link with line states. Since these are not long
frames, they do not stress the elasticity buffer. Thus, if a clock
on the DAS or the concentrator were out of spec, you would not
know it until you were actually using the link to transmit
long frames.

PLEASE do not misread my citing of these pathological cases as
any lack of support for dual homing. I believe it is a valuable
mechanism for enhancing system availability. This is just a
response to Richard's request for hypothetical situations.

By the way, I believe a DAS will preferentially connect through
the B port when given the choice. The Committee decided to do
it this way so that management nodes can draw deterministic
ring maps. I mention this because of the clocking issue
I cited in case 2. If a concentrator connects only to the A ports
of DAS nodes whose B ports are all satisfied by a second concentrator,
and the first concentrator's clock is out of tolerance toward the
fast side, and the two neighbor nodes to the first concentrator were
within tolerance toward the fast side, then you would discover the
problem in a nasty way if the second concentrator failed and
forced all the DAS nodes to connect to the first. Now you will
get occasional elasticity buffer overflows on long frames.
Perhaps a better way to manage a facility is to set up dual homing
connecting half of the concentrator's M ports for A ports and the
other half to B ports... of different stations of course ;-).

Please also note that oscillators drift with time and temperature
so even if you are able to pass long frames within a minute or two
of powering up a device, that does not mean you will continue to be
able to do so after the equipment has been cooking away for a few
hours on a hot day.

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 487 9768
From: grandjean@elgr.epfl.ch
Newsgroups: comp.dcom.lans.fddi
Subject: How perform 30+ Workstation on FDDI?
Date: 10 Oct 92 12:19:26 GMT
Organization: Ecole Polytechnique Federale de Lausanne


I'm working on a project were 30 Workstations will be added to our network.
The Stations will induce heavy nfs traffic (bitmap maps) and SQLnet traffic.
We teach and develop on GIS -Geographic Information System.

As this setup is in new premise, We have the opportunity to design the 
networking of this workcell from scratch.

     We are evaluating multiple ethernet segment  vs  FDDI.

Does anyone have experience with 30+ networked workstations with FDDI?
What are the issue on management and upgradability?
Is there somewhere on the NET performance figure of such configuration
(DEC & SUN hardware)?

Thanks for anyone who can make the point clearer.
--
Daniel Grandjean, Swiss Federal Institute of Technology        __  __
Address:     EPFL SI-DGR, CH-1015 Lausanne, Switzerland       |  \/  |
E-mail:      grandjean@elgr.epfl.ch                           |o ()o _
Phone:       +41 21 693 27 24	(Central European Time)       |__/\__/
Fax:         +41 21 693 27 27                                    __
From: mack@frugal.fibercom.com (Richard Mack)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Dual Homing II
Date: 12 Oct 92 13:28:20 GMT
Organization: FiberCom, Inc., Roanoke, Virginia

In article <qt6j358@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>I've grumbled that this is not good for moving customer packets (e.g.
>B might pass LCT but not be able to move data--I've seen real cases of
>that), but people in X3T9.5 have told me that the more consistent ring
>maps produced by the standard mandated behavior is more important.
>
>
>Vernon Schryver,  vjs@sgi.com

This is a slightly disturbing comment.

Could you please post the situation where a port could pass LCT and not pass
packets? The only thing I can envision would be if the PH_DATA.(request||data)
lines in the concentrator are broken, but the station self-test should be
able to find that.

Dick

-- 
Dick Mack                        PHONE:    (703) 342-6700,  (800) 423-1183
FiberCom, Inc.                   FAX:      (703) 342-5961
P.O. Box 11966                   INTERNET:  mack@fibercom.com
Roanoke, VA  24022-1966          UUCP:      ...!uunet!fibercom!mack
From: gator@vnet.ibm.com
Date: Wed, 7 Oct 92 10:11:48 EDT
Newsgroups: comp.dcom.lans.fddi
Subject: Single attached stations and concentrators

To continue the thread about concentrators and why use them:
>
> |>I want to test a FDDI ring, but I have only SAS cards, and I don't
> |>want to buy a concentrator. Can I do this?, and how ?
>
> SAS to SAS is allowed, ie.; a two `node' ring.  While not `legal', I suppose
> that some implementations will support rings with more than two SAS nodes,
> although I suspect that they would more legitimately be called `A' ports.
>
To answer the original question, can a ring of SAS cards be formed,
the answer is yes, with qualifications. You would have to disable
Connection Management (CMT) in all the SAS stations and would end up
with a single, uni-directional ring.

Most fiber FDDI stations use MIC type recepticles with which to attach
to the ring. A MIC recepticle has the ring in and ring out connectors
housed in a single, rectangular-looking unit. The other type of
connector available is an ST type connector. It looks sort of like a
BNC connector for fiber. An SAS would have two ST connections or a
single MIC recepticle. Fiber cabling is available that breaks the MIC
type connector out to two ST type connectors. Using ST connectors and
a small plastic jumper that allows you to connect two ST connectors
together, one could connect the ring out of the upstream station into
the ring in of the downstream station. In this way, a ring of SAS's
could be created.

David Sips
gator@vnet.ibm.com

My views do not represent the views of my employer.
Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Optical Bypass Switches.
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 13 Oct 1992 17:49:59 GMT

In article <mbt.718988378@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> >Think of tiny mirrors controlled by solenoids with springs.  Literally.
> ...

> Actually I think the actuators are bi-metallic devices that heat and bend
> when the control leads are activated (+5VDC I seem to recall) The mirrors
> are usually prisms I think....


Bi-metalic strips?  Interesting.  That seems likely to require more
power than a coil, but I'm sure I don't know much about such
engineering.

When testing vendors before choosing one to resell, we did find one of
the big guy's did not work as well on marginal power.  Maybe they used
such bimetalic strips.  Or would you expect more such problems from a
coil?

Prisms?  I'd expect such a design to have higher losses compared to
front-surfaced mirrors, but again, I don't know anything about
designing such a thing.

I think I know at least some (e.g. the one we resell) use magnetic
coils, solenoids.   I think those use flat mirrors, but I'm not
certain.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Dual Homing II
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 10 Oct 1992 05:46:45 GMT

In article <92283.160905DART@SLACVM.SLAC.STANFORD.EDU>, DART@SLACVM.SLAC.STANFORD.EDU (415) writes:
> ...
> Does one connect a DAS station as per FIG.1 or FIG. 2 below.  Figure 1 shows
> a  DAS station plugged directly into two concentrators.  Figure 2 shows
> the concentrators cross-coupled.  I believe, and I will be testing this,
> that FIG. 2 is the correct configuration as it's the only way I can see
> that normal token rotation will be maintained.   Does anyone have Dual
> Homing in place?  (My original note follows the figures.)
> 
>           |----------|            |----------|
>  TO     ->|A  CON    |->->->->->->|A         |
>         <-|          |<-<-<-<-<-<-|  SERVER  |
>  DUAL     |    1     |            |    1     |
>         ->|B         |       -->->|B         |
>  RING   <-|   DAS    |      /-<-<-|   DAS    |
>           |----------|     //     |----------|
>                           //
>           |----------|   //
>  TO     ->|A  CON    |-> /
>         <-|          |<-<
>  DUAL     |    1     |            FIG. 1
>         ->|B         |            Direct Dual Homing.
>  RING   <-|   DAS    |
>           |----------|
> 
>           |----------|            |----------|
>  TO     ->|A  CON    |->->->->->->|A         |
>         <-|          |<--       <-|  SERVER  |
>  DUAL     |    1     |   \     /  |    1     |
>         ->|B         |    <-<-<-<-|B         |
>  RING   <-|   DAS    |      /-<-<-|   DAS    |
>           |----------|     //     |----------|
>                           //
>           |----------|   //
>  TO     ->|A  CON    |<- /
>         <-|          |-->
>  DUAL     |    1     |            FIG. 2
>         ->|B         |            Cross-Coupled Dual Homing.
>  RING   <-|   DAS    |
>           |----------|


Fig. 1 is correct.  Fig. 2 will not work with ANSI standard
concentrators or stations.  You can't split connections that way.
CMT signalling will not work in Fig. 2.

All SMT 7.2 compliant DAS vendors "have dual homing in place"
(including Silicon Graphics, of course.)  Dual homing was in use in the
FDDI demo ring at Interop91.

"Dual homing" is only a scheme for having a "hot backup".  When the
connection to the B port of the server fails, the server will finish
CMT signaling on the A port and start using the A port.  When the B
port looks good again, as determined by still more CMT signalling, the
server is required by the SMT standard to shut down the A port and
start using the B port again.

I've grumbled that this is not good for moving customer packets (e.g.
B might pass LCT but not be able to move data--I've seen real cases of
that), but people in X3T9.5 have told me that the more consistent ring
maps produced by the standard mandated behavior is more important.


Vernon Schryver,  vjs@sgi.com
From: hens@snipe.cray.com (Tom Stephens)
Newsgroups: comp.dcom.lans.fddi
Subject: Optical Bypass Switches.
Date: 12 Oct 92 21:04:56 GMT
Organization: Cray Research, Inc.



Can someone tell me how they really work?  Or better yet, point me in a direction where I can read about them?  I am having problems explaining that if two machines are powered off in an fddi ring, they will not isolate the machine in the middle.  Senerio..



Machines on the ring (in order)


x y z a b


x and z are powered off for maintinence.  Can y talk to a or b?  I think that it can, since this is the reason for the OBS's.  The person that I am trying to explain this to is not convinced.  I think I need to tell him how the OBS works, to convince him.   


Any comments/suggestions are welcome, as always.


Tom.
--
---------------------------------
Tom Stephens
Corporate Computing and Networks, Chippewa Falls, WI
Cray Research Inc.  hens@cray.com
Newsgroups: comp.dcom.lans.fddi
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: Can NFS over FDDI work properly?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 7 Oct 1992 09:21:31 GMT

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
+---------------
| I don't know about XNS or IPX, and I can't find any equivalent to the
| IP offset or MF bits in the "Internet Protocol" described in my old
| Xerox XNS documents.
+---------------

There aren't any. XNS doesn't fragment. From the XNS ITP manual [XSIS 028112],
page 21 [ALL CAPS were italics in the original]:

    Internetwork routers must at least forward internet packets of
    this size [576]. INTRANETWORK FRAGMENTATION AND REASSEMBLY must
    be performed by the level zero protocol for transmission systems
    that cannot transmit a correct length internet packet. Two comm-
    unicating clients are free to negotiate a different maximum length.
    
    If the processes negotiate an increase in the maximum length of
    an internet packet, consideration must be given to the possible
    problems of any internetwork routers that may be in the communc-
    ations path. These routers are not a party to the negotiations,
    and in fact cannot be, since the route is dynamic. If a router
    encounters a packet which it cannot handle, it will discard it.
    There is no automatic way to determine whether the routers along
    the way will or will not support packets of a particular size.

I would suppose IPX is the same.


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.lans.fddi
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Re: Looking for an ATM Switch
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 14 Oct 92 13:35:09 GMT

In article <1992Oct14.094150.25376@ntuix.ntu.ac.sg>, mty@ntuix.ntu.ac.sg (Yap Ma Tit) writes:
>I am looking for an ATM (asynchronous transfer mode) switch
>to support our research in high-speed multiservice networks
>and distributed multimedia applications.
>
Please post this request on the comp.dcom.cell-relay newsgroup