HDTenEightyP/NetNews huggingface dataset:
From: ellingsen_jim@Tandem.com (Jim Ellingsen)
Subject: Token-Ring SRT
Followup-To: comp.dcom.lans.misc
Keywords: Token-Ring
Organization: Tandem Computers
Date: Thu, 16 Apr 1992 19:58:51 GMT

Can someone provide me with a description of token-ring source
routing transparent or references to any documents which 
describe it?  The IBM and TI manuals provide a fairly good
description of source routing but I have not been able to 
find anything about SRT.
Thanks,
Jim Ellingsen        ellingsen_jim@tandem.com
Tandem Computers
Cupertino, CA 95014
From: sob@hsdndev.UUCP (Scott Bradner)
Newsgroups: comp.dcom.lans.misc
Subject: FDDI & token ring router & bridge tests at Harvard
Date: 12 Apr 92 23:45:43 GMT
Organization: Harvard University


Well, its that time again.  I'm starting a new round of router &
bridge tests.  This round will deal with FDDI & token ring using the
following arangements: (DUT = Device Under Test, a router or a bridge)

    -------------  -----------  --------------
   /             \ |         | /              \
  < fddi ring #1  >|   DUT   |<  fddi ring #2  >
   \             / |         | \              /
    -------------  -----------  --------------

    --------------  -----------  ---------------
   /              \ |         | /               \
  < token ring #1  >|   DUT   |<  token ring #2  >
   \              / |         | \               /
    --------------  -----------  ---------------

    --------------  -----------        -----------  ---------------
   /              \ |         |        |         | /               \
  < token ring #1  >|   DUT   |==WAN===|   DUT   |<  token ring #2  >
   \              / |         |        |         | \               /
    --------------  -----------        -----------  ---------------

          -----------  ---------------  -----------
up to-----|         | /               \ |         |----- up to
  6  -----|   DUT   |<   fddi ring     >|   DUT   |-----   6
Enets-----|         | \               / |         |----- Ethernets
          -----------  ---------------  -----------

    --------------  -----------  -----------  -----------  --------------
   /              \ |         | /           \ |         | /              \
  < token ring #1  >|   DUT   |<  fddi ring  >|   DUT   |<  token ring #2 >
   \              / |         | \           / |         | \              /
    --------------  -----------  -----------  -----------  --------------

Tests will be run using a number of protocols to measure throughput and
aggregate packet handling ability.  The tests will be run in the Harvard
Network Device Test Lab in Cambridge MA.

The results of the tests will be reported during my tutorial and at a BOF
on Wed night at Interop in DC in May.  The results will also be put
on hsdndev.harvard.edu for anonymous FTP and appear in an article in Data
Communications.

If you have any suggestions for specific tests please let me know.

The tests are open to all vendors who would like to show up, there is no
fee.  There two required and one suggested condition for inclusion:

required:
	1/ the router or bridge hardware and software must be available to
	customers within 3 months of Interop or at the next "normal"
	software release if a calandar-based schedule is used.
	2/ all results of the tests will be reported unless superceded
	during the test period with other results. (i.e. you are allowed
	to fix bugs)

suggested:
	a vendor representative should be present during the tests to
	do the device setup to ensure that it is done correctly.

Please contact me via email at the address below or via phone at
617-495-3864 if you would like to be included.


	Scott Bradner
	sob@harvard.edu
Newsgroups: comp.dcom.lans.misc
Subject: Re: Two devices and only 3 pair?
From: mike@elec.canterbury.ac.nz (Cosmik Debris)
Date: 9 Apr 92 09:07:22 +1200
Distribution: world
Organization: Electrical Engineering, University of Canterbury, New Zealand

In article <j9bd6q4@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
> tg@utstat.uucp (Tom Glinos) writes:
> +---------------
> | I would like to put two xterminals into an office but it only has
> | 3-pair going into the office. Any idea on how to get both running
> | without dragging another pair into the office?
> +---------------
> 
> Put a cheap PC on either end of two of the pairs, and run async SLIP?
> [Each PC would also need an Ethernet interface, assuming your X terminals
> have Ethernet...]
> 
> That leaves you one pair free.  ;-}
> 
> 
> -Rob
> 
> -----
> Rob Warnock, MS-9U/510		rpw3@sgi.com
> Silicon Graphics, Inc.		(415)335-1673
> 2011 N. Shoreline Blvd.
> Mountain View, CA  94039-7311
> 

Surely 3 pairs is sufficient for 2 X-terminals if you make a special cable.

-- 
*******************************************************************************
*  Mike Shurety                           mike@elec.canterbury.ac.nz          *
*  Computer Systems Manager               psi%(5301)30000012::mike            *
*  Electrical & Electronic Engineering    FAX        : (64) (3) 642-761       *
*  University of Canterbury               Phone work : (64) (3) 642-295       *
*  New Zealand                            Phone home : (64) (3) 891-629       *
*                                                                             *
*                      "I owe money, therefore I am"                          *
*******************************************************************************
From: 2frgelect@kuhub.cc.ukans.edu
Newsgroups: comp.dcom.lans.misc
Subject: wireless LAN information requested
Date: 6 Apr 92 19:38:27 CDT
Organization: University of Kansas Academic Computing Services

I am wanting information on wireless local area
networks for a class paper of mine.  I have had
trouble finding recent systems and would
appreciate any information available.
Thank you very much.

D.J. Hatton
telnet volta.ece.ukans.edu
username dhatton
From: paul@ace.acadiau.ca (Paul Steele)
Newsgroups: comp.dcom.lans.misc
Subject: FOIRL transcievers with BNC connector
Date: 13 Apr 92 14:47:38 GMT
Distribution: na
Organization: Acadia University

We are looking for someone that make FOIRL tranceivers that have a thinnet
BNC connector rather than an AUI connector.  The AUI type transceiver works
fine in locations where we only have one 10BaseT hub, but on some places, 
especially labs, we often have 4 or more 10BaseT hubs connected together by 
thinnet, and in these situations we need an FOIRL transceiver with a BNC end.
So far we haven't found anyone who makes such a beast.  The alternative is 
to put a BNC repeater box between an AUI FOIRL transceiver, but that seems 
like a needless expense.  Has anyone got any suggestions on how to handle 
this sort of set up?

___
Paul Steele, Network Services Manager              902-542-2201x660
Acadia University, Computer Centre            FAX: 902-542-7224
Wolfville, Nova Scotia, Canada, B0P 1X0  Internet: Paul@ace.acadiau.ca
Newsgroups: comp.dcom.lans,comp.sys.novell
From: cspecwc@ustores.ustores.missouri.edu (Bill Canning)
Subject: Bridge Filtering on Token Ring
Organization: Computer Spectrum, University of Missouri - Columbia
Date: Mon, 13 Apr 1992 20:57:23 GMT

(This may have already been posted.  If so, I apologize...)

We have a Token Ring network here with multiple bridges, etc., that has about
70 Novell servers on it.  In addition, this network has numerous bridges, 
routers, mainframes, 3270 controllers, Unix workstations, etc. attached.

The network uses source routing bridges to connect rings to the backbone.  My
problem is that I just attached a new remote bridge to our local ring (which
attaches to the backbone by another S-R bridge).  This bridge works fine, but
is the 56Kbps DDS line that the bridge halves communicate over seems to be
quite full even when there is no activity on the remote ring.

Using the statistics gathering screen of the bridge program (IBM Token Ring
Bridge Program V2.2), I found that in a 10 minute period, we had received
1.2+ MBytes of broadcast data over the bridge, compared to <5 KB of non-
broadcast data.

The people on the remote ring only need to get to the other side of the bridge
(one hop) for most data, and some mainframe communication via either telnet or
PC/3270.  Is there any way I can cut down on the ammount of traffic over this
bridge without messing up something else?

Any help you could offer would be greatly appreciated.

Bill Canning
Microcomputer Support Specialist
University of Missouri - Columbia
From: Rolly_Noel@quick.ucs.ualberta.ca (Rolly Noel)
Newsgroups: comp.dcom.lans.fddi
Subject: FDDI Concentrator Performance
Date: 15 Apr 92 19:52:23 GMT
Organization: University of Alberta

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?
Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Daisy chaining SAS FDDI workstations
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 8 Apr 1992 08:00:44 GMT

In article <1992Apr7.021703.18107@berlioz.nsc.com>, my@laverde.nsc.com (Mike Yip) writes:
> 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!
> 
> 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.  ;-)


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.

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

None of that paragraph is academic.  Many unsuspecting people have bought
my implementation of PCM.  (It's handy to have good marketeers).  I've
built and played with the non-PCM hacks.

The justification for PCM and SMT in general is "fault domain isolation",
locating whatever is broken when things don't work right.


Vernon Schryver,  vjs@sgi.com

(shouldn't we be talking about "CMT" instead of "PCM"?  Oh well, I can
never keep TLAs straight, especially the FDDI TLAs which all include the
word "management")
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: comp.dcom.lans.fddi
Subject: RFI: HP Dual-Attach for HP Model 7xx
Date: 11 Apr 92 16:43:35 GMT
Distribution: usa
Organization: Naval Research Laboratory, DC


  I expect to receive a couple of HP 7xx workstations with dual-attach
FDDI cards in the next month or two.  I'd be interested in hearing any
experiences that others might have had with such beasties.  I'd also
be interested in hearing which chipset HP used to build the things
and whether my expectation that SMT 6.2 is supplied is in fact correct.

  I will summarise any email I receive back to the net.

Ran
atkinson@itd.nrl.navy.mil
From: my@berlioz.nsc.com (Mike Yip)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: FDDI and ethernet address spaces
Summary: Bit swapping
Keywords: MAC Address, 48-bit, 16-bit, bit swap, FDDI
Date: 14 Apr 92 05:41:34 GMT
Organization: National Semiconductor Corp.

In article vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>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.
Well, in a closed enviornment, say the space shuttle or an airplane,
someone might want to use the 16 bits address on the equipment.  For example,
the missile launch control board will always have the same MAC address
on every plane so that a statistic collection board somewhere can dump
and identify net traffic easily.  ;-)  I have no idea how useful the 16-bit
address is, but someone somewhere will think of some strange reason to use it.

>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.
Agree.  But someone somewhere might want to save that 24 instructions.
Especially in bridge/router situations.  I think that some routers or 
bridges that use one (combined) hardware CAM (Content addressable memory)
to do big time address recongnition will like to use only one bit order.
For example, a FDDI-Enet bridge might want to use the enet bit order in 
the CAM only.

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

>bridge trying to break 500,000 packets/second.  I don't know about bridges,
>except that I think they are a stupid idea.
Agree.


-- 
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 
| Of course, this is my own opinion!
From: sakurai@marugw.maru.prug.or.jp (Yutaka Sakurai)
Newsgroups: comp.dcom.lans.fddi
Subject: Network Peripheral
Date: 16 Apr 92 09:24:00 GMT
Organization: Packet Radio User's Group

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
Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: FDDI Concentrator Performance
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 16 Apr 1992 08:11:11 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?


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

Newsgroups: comp.dcom.lans.fddi
From: stephan@idt.unit.no (Eirik Morten Stephansen)
Subject: Where to get ISO 9314,1-3
Organization: University of Trondheim, Norway
Date: Tue, 7 Apr 92 19:58:43 GMT

From Dwight A. Ernest (dwight@hyphen.com) I got this question

> It's helpful and kind of you to post the ISO standard reference,
> but most people, I think, including myself, do not know how to
> get access to these documents.  Where can one order these ISO
> documents?

I am working on a FDDI-project (constructing a FDDI-part for a 486 Single Board Computer). To get the ISO FDDI standard I went to the university library. There all the ISO standards is kept on a microfishe (almost a micro-film).

In case you want to order the documents from ISO, you can write to:

  International Organisations for Standards
  Case postale 56
  CH-1211 Geneve 20
  Switzerland

I hope this would help.

Eirik S.
From: larry@xlnt.com (Larry Pollack)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: SMT Standard
Keywords: SMT, ANSI, FDDI, 7.0, 6.2
Date: 8 Apr 92 16:28:49 GMT
Reply-To: larry@xlnt.com
Organization: XLNT Designs, Inc.

In article <1992Apr6.020313.18075@berlioz.nsc.com>, my@berlioz.nsc.com (Mike Yip) writes:
|> 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.
|> 

The term "interoperability" seems to have too many definitions when discussing
SMT issues. It is certainly true that stations using SMT 6.2 will connect to and
coexist with stations using SMT 7.x. Even stations using SMT 5.1 could be on the
same network. Enough compatibility exists between SMT 7.x and older SMT
revisions to allow an outside entity, like a management station, to distinguish
the difference. This has been a goal of the SMT committee.

The 7.x revision is expected to become the FDDI SMT standard document. Thus,
revisions prior to 7.x are NOT standards. Once a standard is accepted, where
does that put the non-standard implementations? Although current SMT
implementations interoperate with each other, they also have vastly different
behavior in some areas. Will there be companies producing management systems
that understand BOTH standard and non-standard implementations of SMT? It is
possible to build a management station to understand older revisions of SMT, it
is not likely that it could understand implementation-specific behavior. I would
expect most FDDI stations to be upgraded to the standard once it is accepted.

-Larry.

/======================================================================\
| Lawrence J. Pollack                   | Your source for FDDI SMT.    |
| Senior Software Engineer              |                              |
| XLNT Designs, Inc.                    | Voice   : 619-487-9320       |
| 15050 Avenue of Science, Suite 106    | Fax     : 619-487-9768       |
| San Diego, CA 92128  USA              | Internet: larry@xlnt.com     |
\======================================================================/
Xref: sparky comp.dcom.lans.fddi:232 comp.protocols.tcp-ip:2522
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.fddi,comp.protocols.tcp-ip
Subject: Re: ARP over FDDI and "canonical bit order"
Date: 15 Apr 92 03:40:39 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

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

An ARP frame on the ring contains two addresses in the MAC header (one
often broadcast) in FDDI bit order.  An FDDI ARP frame also contains MAC
addresses in its body, but in ethernet bit order.

All FDDI stations expect this, and do what's necessary.  There's no
reason for them to be confused.
 
>                                                          ... 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.

The reasoning behind bridges is that you can't tell if the other guy is on
the same fiber as you, on an ethernet bridged to your fiber, or even a
fiber bridged to an ethernet bridged to your fiber.

Thus, we all transmit hardware type 1 in ARP packets, but many of us are
prepared to accept 6.

As long as everyone uses packet sizes <= 1500 bytes, everything works
fine.  The bridges reverse the bits of the MAC headers as they copy between
ethernet and fiber.  That is among the easy parts of making an FDDI
bridge.


> Is this standard broken ....


Things work just fine, as long as everyone is willing to give up as much
as 60% of their performance by not using 4KByte frames.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.lans.fddi,comp.protocols.tcp-ip
From: demon@sequent.com (Dave Richards)
Subject: Re: ARP over FDDI and "canonical bit order"
Organization: Sequent Computer Systems Inc.
Date: Wed, 15 Apr 92 15:28:49 GMT

In article <1992Apr14.193459.28218@mcnews.mcdata.com> ddb0248@mcnews.mcdata.com (David Beal) writes:
>And, while we're at it,
>how does this work on token ring, which has the same bit order as FDDI ?

I thought Token Ring used the same order as FDDI too.  However, when we
started doing our interoperability testing, we found that it was not true.
I added a new flag to our ARP implementation which is defined during
initialization which indicates whether the interface uses canonical or
non-canonical MAC addresses.  Currently Ethernet, IEEE 802.3 and FDDI use
the canonical form and IEEE 802.5 uses the non-canonical form.  Which
is a pain, because I'm starting to turn bytes upside down in my sleep. :-)

	Dave Richards
	Sequent Computer Systems
From: rasp@xlnt.com (Ron Perloff)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: SMT Standard
Date: 8 Apr 92 18:45:34 GMT
Organization: xdi

In article <1992Apr6.020313.18075@berlioz.nsc.com> my@berlioz.nsc.com
(Mike Yip), in referring to version 7.x of the draft SMT standards writes:

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


As I noted in my earlier posting, for basic connectivity and data
movement, there is NO PROBLEM in making stations using version 7.x
SMT interoperate with stations employing older versions. However,
when you try to manage such stations the older versions of the SMT
draft standard create some difficulties. Since network management
is such a big issue with today's buyers, this creates a practical,
i.e. business, problem for board and system vendors.

Here are some of the major issues:

Some portions of the version 6.2 SMT protocol were broken. In
order to build structures such as concentrators, we at XDI had to
design OUR own 'private' version of the paths portion of the
protocol. Other SMT implementers designed THEIR own fixes. Someone
writing a network management application would have a VERY
difficult time sorting things out. Version 7.0 of the draft
standard presents a new, correct paths protocol.

Older versions of the SMT protocol ignored flexible
configurations. Organizations building devices allowing power-on
insertion and removal of boards again had to develop private
solutions for distinguishing between existing and potential
configurations. Again, in a heterogeneous environment with diverse
solutions, one has a management problem. Version 7.0 corrects it.

Version 7.0 of the draft standard makes PMF Get responses
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.

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