dave@exloghou.portal.com (Dave St.Clair) (03/27/91)
The subject kind of says it all, my company is connecting two TCP/IP LAN's consisting of mostly of SUN SparcStations by a 64K leased line. I'm looking for a bridge/router that will turn these two nets into one virtual net. We only use TCP protocol. I've got reams of propoganda from various vendors, but no first hand testimonials. Proposed traffic over the line is about 50M/day, with 75% being file transfer, 25% interactive. It is possible we may increase the bandwidth to 128K or 256K over time. I guess I'm interested in the product that will give me the best through-put for the money. Dave St.Clair EXLOG, Inc dave@exloghou.portal.com
ccrth@lut.ac.uk (Rob Thirlby) (03/31/91)
Organization : Loughborough University, UK. Keywords: Bridge Router 64K Spider Ltd make a 64 K bridge which has a good reputation in the UK. I can provide an address is you are interested. We have an "Intracomm" bridge with G703 interface operating at 2mb which has performed well for a couple of years on a BT Megastream circuit. (T1 equivalent?). rob thirlby
martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo) (04/06/91)
> The subject kind of says it all, my company is connecting > two TCP/IP LAN's consisting of mostly of SUN SparcStations by > a 64K leased line. I'm looking for a bridge/router that will > turn these two nets into one virtual net. We only use TCP protocol. > I've got reams of propoganda from various vendors, but no first hand testimonials. Clearpoint Research Corporation makes a high performance ethernet spanning-tree mac level bridge which can transparently connect two geographically distant networks via serial connections. There are two RS-449 ports which can do at least 64kbps and which can load share when properly configured. The RS-449 ports can be jumpered to signal as RS-232 so that with relatively standard RS-449 to RS-530 conversion caables the bridge can be connected to RS-232 interfaces. > Proposed traffic over the line is about 50M/day, with 75% being > file transfer, 25% interactive. It is possible we may increase > the bandwidth to 128K or 256K over time. This should not be a problem. I have run NFS over the serial interface and have generally barely noticed and then only when trying to load a tremendously huge program. > I guess I'm interested in the product that will give me the best > through-put for the money. The Little Dipper gives the theoretically maximum throughput and is very competitively priced product with lots of neat features like a remote telnet interface. I would buy it but then I am one of the designers. The Little Dipper has in maximal configuration 8 ethernet interfaces. The ethernet interface cards have 3 connectors: MAU, DTE and BNC. The connector in use is autodetected. An ether-TWIP interface is in the works. Depending on configuration, the box has 2 or 3 wan channels. We advertize the WAN channels as 64 kbps links but WAN Channels 1 and WAN Channels 2 use high performance DMA and I have run them at 384 kbps. Currently, ethernet packets are bridged serially via simple raw hdlc encapsulation. An imminent software release will support 1984 and 1988 X.25 as well as load-sharing between WAN Channels 1 and WAN Channels 2 when they are configured as raw hdlc channels. The box supports server and client telnet, responds to ping requests and has a screen oriented/Forms&Menu based user interface. The box may be managed through an RS-232 control terminal port or via an incoming telnet connection. Forwarding between paired ethernet interfaces achieves the theoretical ethernet maximum of ~56,400 packets with more than enough cycles left over either to saturate completely serial links which are transmitting or to receive packets without dropping from a completely saturated serial link. A near term release will support SNMP for management of the ether, serial, IP and X.25 interfaces. A slightly more distant release will support IP routing. The current release does filtering at the MAC level. My phone number is (508)-435-7466. You may call me. Of if you prefer you may send me your address and phone number and I can put you in touch with a local salesperson. > Dave St.Clair > EXLOG, Inc > dave@exloghou.portal.com Joachim Carlo Santos Martillo Ajami
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (04/08/91)
In article <11659@cpoint.clearpoint.com>, martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo) writes: > > Clearpoint Research Corporation makes a high performance ethernet.... [and so on for about 70 lines.] I sent the author the following note: > > Please try to avoid such advertising. There are many other solutions > > available for the requester's needs, most from vendors with employees who > > read this news group. > > > Vernon Schryver, vjs@sgi.com The response contained direct insults, and included an observation that the Clearpoint article was similar to <1991Mar30.185821.7385@lut.ac.uk> about Spider's bridge, differing only in length. Was I wrong in finding the Clearpoint article past the edge of non-commericalism? Would it be wrong to ask that such lead chasing be conducted by email, with summaries to the net by the original requester? Would it be too much to ask that such product announcements be concise enough to fit on a single 80-line screen? Vernon Schryver, vjs@sgi.com
martillo@crackers.clearpoint.com (Martillo) (04/08/91)
In article <95891@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >In article <11659@cpoint.clearpoint.com>, martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo) writes: >> Clearpoint Research Corporation makes a high performance ethernet.... > [and so on for about 70 lines.] >I sent the author the following note: >> > Please try to avoid such advertising. There are many other solutions >> > available for the requester's needs, most from vendors with employees who >> > read this news group. >> > Vernon Schryver, vjs@sgi.com >The response contained direct insults, and included an observation that the >Clearpoint article was similar to <1991Mar30.185821.7385@lut.ac.uk> about >Spider's bridge, differing only in length. The following is my response to Schryver's obnoxious attempt at being net-cop. ================================= Begin Response > Please try to avoid such advertising. There are many other solutions > available for the requester's needs, most from vendors with employees who > read this news group. > Vernon Schryver, vjs@sgi.com Excuse me, but my article does not differ significantly from the appended article except in having more information content. My article was framed as a reply to the original article with comments on specific points in the original article. As such, it is not advertising but purely informational and I for one would be interested in similar articles from designers of the other boxes. As such, your presumptuous attempt at being net-cop is most impudent, improper, impolite and unwanted. If a person wants a sales pitch, he can write to me and I would be perfectly willing to get him a sales contact (just as Thirby below is willing to supply addresses). The sales contact would be more than happy to supply genuine advertisements, but I personally do not do sales. With all due respect, Joachim Carlo Santos Martillo Ajami >From crackers!samsung!rex!wuarchive!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!warwick!nott-cs!lut.ac.uk!ccrth Sat Apr 6 20:35:47 EST 1991 Article: 5550 of comp.dcom.lans Path: cpoint!crackers!samsung!rex!wuarchive!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!warwick!nott-cs!lut.ac.uk!ccrth From: ccrth@lut.ac.uk (Rob Thirlby) Newsgroups: comp.dcom.lans Subject: Re: WAN Bridge/Router over Fractional T1 (64K) Message-ID: <1991Mar30.185821.7385@lut.ac.uk> Date: 30 Mar 91 18:58:21 GMT References: <1991Mar27.152925.8267@exloghou.portal.com> Reply-To: R.Thirlby@lut.ac.uk(Rob Thirlby) Organization: Loughborough University, UK. Lines: 12 Organization : Loughborough University, UK. Keywords: Bridge Router 64K Spider Ltd make a 64 K bridge which has a good reputation in the UK. I can provide an address is you are interested. We have an "Intracomm" bridge with G703 interface operating at 2mb which has performed well for a couple of years on a BT Megastream circuit. (T1 equivalent?). rob thirlby ================================= End Response >Was I wrong in finding the Clearpoint article past the edge of >non-commericalism? Would it be wrong to ask that such lead chasing be >conducted by email, with summaries to the net by the original requester? >Would it be too much to ask that such product announcements be concise >enough to fit on a single 80-line screen? You were totally wrong. I spent time trying to provide a useful article which replied meaningfully to the original article and provided some useful information from the designer's viewpoint. Such an article is exactly the type of article which is useful to me and which I would like to see. As for being a product announcement, my article was not a product announcement. If it had been, it would have contained less useful information. My current thoughts about valuable features for a high-performance LAN-WAN Bridge-Router are not binding upon Clearpoint and are subject to change as I gather information from sources like this newsgroup. As for insults, I have no reluctance to abuse an arrogant self-appointed net-cop. If you cannot deal with such abuse, I suggest you don't appoint yourself net-cop. Nescio quid mihi magis farcimentum esset quam sententia Vernonis. >Vernon Schryver, vjs@sgi.com Joachim Carlo Santos Martillo Ajami
andrew@jhereg.osa.com (Andrew C. Esh) (04/10/91)
I would just as soon see the sales information (not pitch), as long as it's short (2 pages max) and in direct response to an inquiry by another poster. In comp.sys.mac.* we get all kinds of product reviews, most of the time without even asking. To be a player in the lan world, you need to know your boxes. I say, let 'er rip. :-) -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Minneapolis, MN 55416-1528 (612) 525-0000 Practicing the OSI Standard
dag@fciva.FRANKCAP.COM (Daniel A. Graifer) (04/10/91)
We are using a pair of CrossCom ILAN-1 (TM) to bridge the ethernets in our Northern Virginia and Orange County, S. Calif. offices. Each unit has four slots which will accept any mix of T1, Fractional T1, ethernet and token ring cards. We've had no problems with the units, and we plan to bridge another office later this summer: Just drop another card in one of the units. We went this way because when we bought them, we thought we might be bridging a Token-Ring based office, but that project collapsed. They still seem to be excellent units. We've had no problems. The biggest problem was getting MCI/PacTel/C&PTel to get their act together on the line. It didn't help that one of our DSUs was DOA. If you do mix Ethernet and Token ring, remember that a bridge provides a connection at MAC (Data Link) Layer. Getting Network Layer datagrams originally designed for the other media into your hosts is another matter. CrossCom can be reached at 1-800-388-1200 or 1-508-481-4060. Disclaimer: We have no connection to CrossCom except as satisfied customers. Oh, we bought our units through Glasgal (a big comm equip. distributor). Dan -- Daniel A. Graifer Coastal Capital Funding Corp. Sr. Vice President, Financial Systems 7900 Westpark Dr. Suite A-130 (703)821-3244 McLean, VA 22102 uunet!fciva!dag fciva.FRANKCAP.COM!dag@uunet.uu.net
rg@gandp (Dick Gill) (04/12/91)
In article <95891@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >In article <11659@cpoint.clearpoint.com>, martillo@cpoint.clearpoint.com (Joachim Carlo Santos Martillo) writes: >> >> Clearpoint Research Corporation makes a high performance ethernet.... > [and so on for about 70 lines.] > >I sent the author the following note: > >> > Please try to avoid such advertising. There are many other solutions >> > available for the requester's needs, most from vendors with employees who >> > read this news group. >> >> > Vernon Schryver, vjs@sgi.com [stuff deleted] >Was I wrong in finding the Clearpoint article past the edge of >non-commericalism? Would it be wrong to ask that such lead chasing be >conducted by email, with summaries to the net by the original requester? >Would it be too much to ask that such product announcements be concise >enough to fit on a single 80-line screen? > > >Vernon Schryver, vjs@sgi.com Yes, you were wrong. Far from a product annoncement, the posting was a well written and concise description of the product that he had designed to solve the problem posed by the original poster; I wish that just HALF of what I see on the net was this informative !-) I don't know who has what agenda in this complaint, nor do I parrticularly care. I for one am delighted that hardware and software designers have a forum to discuss their creations and enlighten those of us who need more information but find marketing brochures a bit to fluffy. As to the 'commercialism' aspect, I suspect that everyone on the net gets paid by SOMEONE, and that postings like the one in question are no more biased than most others. Besides, he actually had something useful to say !-) -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dick Gill Gill & Piette, Inc. (703)761-1163 ..uunet!gandp!rg
emv@ox.com (Ed Vielmetti) (04/13/91)
In article <95891@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
Was I wrong in finding the Clearpoint article past the edge of
non-commericalism?
Yes. The Clearpoint article was informative, and provided an
appropriate amount of detail to the reader to determine whether the
product was interesting or not. It would not have been an appropriate
article in comp.sys.sgi, but in comp.dcom.lans it was quite
reasonable.
In particular it let me determine what the Clearpoint product was not
going to be interesting in the short to medium term because it did not
support the point to point protocol (ppp), and that is a primary
requirement for routers/bridges that I am now evaluating.
Would it be wrong to ask that such lead chasing be
conducted by email, with summaries to the net by the original requester?
It was not clear that this was lead chasing, any more that it would be
lead chasing for you to mention that SGI boxes do real fast FDDI in a
group that sometimes discussed FDDI. If this were a mailing list with
a set policy of encouraging summaires to the list (e.g. sun-managers),
then the posting would have been inappropriate; but this is
comp.dcom.lans, and in this group there's plenty of discussion.
Would it be too much to ask that such product announcements be concise
enough to fit on a single 80-line screen?
Product announcements are traditionally confined to comp.newprod,
though some vendors do have their own newsgroups (e.g.
comp.dcom.lans.cisco) on which new products are mentioned. I'm quite
sure that SGI products are discussed by SGI people on comp.sys.sgi.
--
Msen Edward Vielmetti
/|--- moderator, comp.archives
emv@msen.com
"With all of the attention and publicity focused on gigabit networks,
not much notice has been given to small and largely unfunded research
efforts which are studying innovative approaches for dealing with
technical issues within the constraints of economic science."
RFC 1216martillo@crackers.clearpoint.com (Martillo) (04/16/91)
In article <EMV.91Apr12190323@poe.aa.ox.com>, emv@ox.com (Ed Vielmetti) writes: > In particular it let me determine what the Clearpoint product was not > going to be interesting in the short to medium term because it did not > support the point to point protocol (ppp), and that is a primary > requirement for routers/bridges that I am now evaluating. > Msen Edward Vielmetti > emv@msen.com The Clearpoint Little Dipper is at present a transparent bridge. According to the current indices at sri-nic.arpa there is no RFC specifying the use of PPP as an encapsulation for transparent bridging over WAN links. And of course, there are no national or international standards for such a specification. Consequently, Vielmetti's comment is rather puzzling. I believe I have seen a draft of an RFC for using PPP as an encapsulation for transparent bridging over WAN links but this draft was in such a rough state that following it would not be appropriate to use as a specification. After seeing Vielmetti's comment, I reread RFCs 1171 and 1172. This rereading reinforced my conclusion PPP is rather inelegant, mostly harmless and not terribly relevant. I) INELEGANCE A) Addressing, CCITT, the PTTs and ISO The addressing structure of the CCITT LAP protocols is one of their many irritating features. LAPD provides a slight improvement but not much. I assume that the frame format specified on RFC 1171 p. 5 is an attempt to make PPP "compatible" with the CCITT protocols in the hope that ANSI, ISO or the CCITT might make PPP a national or international standard. If such is the case, the attempt is pointless. Such standards are expressions of national and international policy. Unless the US State Department takes interest (extremely unlikely), PPP will have no success whatsoever. There are good reasons for the absence of probability of success: 1) The PPP RFCs suggest no obvious method of billing except perhaps timed circuit or leased-line billing. 2) The PTTs are ill-disposed to DARPA Internet style computing and all protocols associated with such networking systems. 3) ISO is committed to a very different architecture of computer networks than the DARPA Internet uses and association with the DARPA Internet will prevent any acceptance of such a standard. Billing is a serious issue because people use packet networks when they want to be billed on a per-packet basis. But in an internet, who should be billed? The endpoint or the person who contracts for an intermediate link. Also IP packets in an internet have no fixed route through a concatenated network and the medium is unreliable. Concatenated networks are a big no-no for the PTTs because they allow the possibility of tail-end hop-off in that packets may hop in and out of public networks to avoid long distance charges. Such routing is generally illegal in a large part of the world. ISO accepts and reflects the needs and preference of the PTTs. In ISO OSI, the communications subnet contains all the networking logic and provides end-to-end service to relatively simple end terminals which take no part in the actual networking logic. The DARPA Internetwork assumes that the communications subnet might be rather simple (like an ethernet coaxial cable for example) and that network hosts which could be relatively powerful computer systems will take part intimately in the actual logic or routing packets through the network. Both models have their domain of application, but even with the frills, ornamentation and its somewhat antique style, PPP belong more to the ARPA Internet model than to the ISO OSI model. B) Frame Check Sequence RFC 1171 p. 7 and p. 8 states the following. "The Frame Check Sequence field is normally 16 bits (two octets). By prior agreement, consenting PPP implementations may use a 32-bit (four-octet) FCS for improved error detection." Actually, if dial-up service is to be permitted, I would argue that in the interest of convenience for network administrators the type of FCS should actually be autodetected. In fact, autodetecting the FCS in this situation is so easy that I have to wonder whether the members of the IETF who worked on this part of the specification actually had much experience with implementing this sort of protocol. II) HARMLESSNESS a) The PPP Link Control Protocol (LCP) The FSA is rather ornate, but I will admit to having had to code protocols with even more complicated crenelations, so I guess it could be worse. Personally I prefer the Link Control Protocol associated with Ethernet 2.0 perhaps with the addition of a very simple ping-pong procedure. b) PPP counters and Link-Manager Packets These are rather entertaining, and I can understand why the telephone companies keep and exchange such information over their links. But in DARPA Internet style computer networking, this information should be kept local and be available via applications which use protocols implemented on top of IP. In this way information is potentially available across a concatenated network. Of course, there is nothing harmful about exchanging such information via link-level packets. The effort for such information exchange is simply reduplicative of efforts which *must* be done elsewhere. III) IRRELEVANCE Since PPP is basically a link-level encapsulation with delusions of grandeur, this protocol is essentially irrelevant for any sort of sophisticated computer networking via serial links. Generally, transmitting data over serial links requires sophisticated user-transparent load-sharing over connections, which might be both packet and circuit connections as well as user-transparent programmed link and band-width allocation. PPP provides no mechanism for such procedures, which is not necessarily within the purview of PPP anyway. But since the bridge-router boxes at both ends of the circuits must agree on the implementation of such procedures, the actual encapsulation specification is basically more irrelevant to the customer user than the internal bus structure of the bridge-router box. Now it is possible that the IETF expects the bridge-router box at one end of the link to communicate directly with an end host at the other end of the link, in which case a bare-minimum lingua franca serial communications access method has more importance than I would otherwise ascribe to such a thing, but my market analysis implies that the number of customers who desire such a configuration is simply too small for company resources to be devoted to development of a product which targets this specific need. There is actually a more sophisticated issue with computer networking over serial links. Doug Comer discusses this issue in Internetworking with TCP/IP, Vol. I, Second Edition. On pg. 151, he writes the following. "Recall from Chapter 2 that some wide area networks contain multiple packet switches. For example, the Cypress network consists of gateways that connect to an Ethernet local area network as well as to other Cypress gateways over leased serial lines. Cypress transfers IP datagrams but uses its own internal packet protocol when transferring them across serial lines. The Cypress serial line protocol software must be merged with other protocols, and the question arises: "How do the Cypress protocols fit into the TCP/IP layering scheme?" The answer depends on how the designer views the serial line interconnections. From the perspective of IP, the set of point-to-point connections among gateways can either function like a set of independent physical networks, or they can function collectively like a single physical network. In the first case, each physical link is treated exactly like any other network in the internet. It is assigned a unique (class C) network number, and the two hosts that share the link each have a unique IP address assigned for their connection. Routes are added to the IP routing table as they would be for any other network. A new software module is added at the network interface layer to control the new link hardware, but no substantial changes are made to the layering scheme. The main disadvantage of the independent network approach is that it proliferates network numbers (one for each connection between two machines), causing routing tables to be larger than necessary. The second approach to accomodating point-to-point connections avoids assigning multiple IP addresses to the physical wires. Instead, it treats all the connections collectively as a single, independent IP network with its own frame format, hardware addressing scheme, and data link protocols. Cypress uses the single network approach and has only one network number for all point-to-point connections." PPP does not even address the issue of architecting IP networks over serial links (except for a tiny reference to a 3rd approach, which Comer apparently dismisses or ignores and which is to set up the two hosts at the end of a serial connection as half-gateways). Since PPP does not address the question of architecting an IP network which use multiple serial links, PPP is essentially irrelevant from the standpoint of a system architect (like me) and from the standpoint of the customer or network administrator who has an internet which consists of several networking technologies including serial links. In order to address the question of architecting an IP network which uses multiple serial links, I have architected into the Little Dipper a high-performance intranetwork system similar to the Cypress Intranet Network architecture. Even if both Little Dippers and the boxes of other vendors both talk PPP, unless the boxes of the other vendors conform to the Little Dipper intranetwork architecture, the Little Dipper and these other boxes really will not interwork. The Little Dipper will also support configuring individual serial links as IP networks as well as half-gateway and half-bridge configuration. This sort of flexibility, which directly addresses the implementation of serial IP networks, is probably more desirable than mere PPP (which will also be present). Basically, if a customer only cares about PPP, and purchases boxes simply on the basis of conformance to this specification, this customer will probably have to be content with low performance serial computer networking. IV) CONCLUSION I must wonder about this continual insistence on PPP, which is merely a link-level encapsulation and which does not address any of the real issues of using serial links as a medium for an IP network. When I took part in T1D1 (currently divided into T1S1 and T1E1 and maybe some other committees), I remember that the members of the committee were reluctant to standardize on the international standards without making qualifications which would require supplemental documents. The members were afraid that if they produced no documents, their managements would get upset that the companies had spent money unnecessarily to send representatives to T1D1. People who worked on PPP through the IETF might have a similar interest in demanding the use of PPP in bridges and routers because otherwise their managements might wonder why the companies spent money to send representatives to take part in the IETF deliberations on PPP. In the future, I would hope that people who discuss PPP issues would make clear whether they might be motivated by such an interest. I personally have no stake in PPP, and to tell the truth while PPP looks to me like another RDP or less, I am willing to be persuaded otherwise. Joachim Carlo Santos Martillo Ajami The above comments represent my current thoughts as system architect. They may change as I study issues more deeply and read the comments of thoughtful critics. The above comments are not product announcements and are in no way binding on Clearpoint Research Corporation.
emv@ox.com (Ed Vielmetti) (04/17/91)
In article <1936@crackers.clearpoint.com> martillo@crackers.clearpoint.com (Martillo) writes:
I believe I have seen a draft of an RFC for using PPP as an
encapsulation for transparent bridging over WAN links but this draft was
in such a rough state that following it would not be appropriate to use
as a specification.
See nnsc.nsf.net:/internet-drafts/draft-ietf-pppext-bridging-01.txt;
comments on that draft can go to fbaker@acc.com (F. Baker of Advanced
Computer Communications). It does look rather rough. I'm sure he'd
welcome your input.
After seeing Vielmetti's comment, I reread RFCs 1171 and 1172. This
rereading reinforced my conclusion PPP is rather inelegant, mostly
harmless and not terribly relevant.
Inelegant, perhaps. Irrelevant, not, not to my design criteria;
everything has to speak PPP, everything has to work together, and
proprietary serial protocols are out.
...Unless the US State Department takes interest (extremely
unlikely), PPP will have no success whatsoever.
PPP competes in a marketplace where protocols do not need to be
blessed by government agencies. As such the US State Department
doesn't need to care one way or another. And the marketplace has
showed willingness to adopt PPP for sync and async applications -- in
particular, cisco and Telebit are shipping products right now that
interoperate well. (i'm working on a real list.) Interoperability,
not blind conformance to standards documents, is the measure of
utility in a large, diverse, potentially hostile environment.
Both models have their domain of application, but even with the frills,
ornamentation and its somewhat antique style, PPP belong more to the
ARPA Internet model than to the ISO OSI model.
III) IRRELEVANCE
Since PPP is basically a link-level encapsulation with delusions of
grandeur, this protocol is essentially irrelevant for any sort of
sophisticated computer networking via serial links....
In order to address the question of architecting an IP network which
uses multiple serial links, I have architected into the Little Dipper a
high-performance intranetwork system similar to the Cypress Intranet
Network architecture. Even if both Little Dippers and the boxes of
other vendors both talk PPP, unless the boxes of the other vendors
conform to the Little Dipper intranetwork architecture, the Little
Dipper and these other boxes really will not interwork.
I'm not entirely familiar with Cypress, though I understand that it
has an innovative approach to wide-area networking. Have enough of
the specifications been published so that a competitor of yours could
could produce a product which would interoperate with yours? The
Internet market shies away from proprietary solutions whenever
possible.
Until that point I must say again that for my application, a box
without PPP is quite useless. Some other people might have
applications which could deal with single-source, proprietary, or
undocumented protocols; they could afford always to buy things in
pairs and pay whatever price you were going to ask and deal with your
level of support. I would think that they might be interested in your
product if it were better/faster/cheaper than the rest as long as
interoperability was not an issue. (just don't bother showing it at
Interop.)
IV) CONCLUSION
I must wonder about this continual insistence on PPP, which is merely a
link-level encapsulation and which does not address any of the real
issues of using serial links as a medium for an IP network.
PPP in the ordinary realm of interest addresses the two questions of
"my cisco doesn't talk to my Proteon on a high speed wire" and "SLIP
is just too horrible to use for real networking". PPP as a packet
format for bridging is not yet standardized and has still a ways to go
before the market proves its utility. Hard to say when or whether
that will be.
Read comp.dcom.sys.cisco in the last week or so and see what real
people other than myself are haggling over.
People who worked on PPP through the IETF might have a similar interest
in demanding the use of PPP in bridges and routers because otherwise
their managements might wonder why the companies spent money to send
representatives to take part in the IETF deliberations on PPP.
In the future, I would hope that people who discuss PPP issues would
make clear whether they might be motivated by such an interest. I
personally have no stake in PPP, and to tell the truth while PPP looks
to me like another RDP or less, I am willing to be persuaded otherwise.
I have attended two IETF meetings, one because it was in town and the
other because I insisted. I have no financial stake in any particular
implementation of the protocol, and I can't claim credit for writing
any PPP code. Your assertion that PPP proponents are somehow
justifying trips to Reno by flogging the utility of the protocol in
public is disingenous.
My interest in PPP is simple. UUCP is a dead protocol, and something
needs to replace it. SLIP would have been the likely alternative
except that it's too brittle, and PPP appears to have enough hooks in
it to make it managable and workable. Similarly, proprietary high
speed serial protocols make it uneconomical to mix and match routers
of various vendors on a network.
Joachim Carlo Santos Martillo Ajami
The above comments represent my current thoughts as system architect.
--
Msen Edward Vielmetti
/|--- vice president for research, MSEN Inc.
emv@msen.com
"With all of the attention and publicity focused on gigabit networks,
not much notice has been given to small and largely unfunded research
efforts which are studying innovative approaches for dealing with
technical issues within the constraints of economic science."
RFC 1216vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (04/17/91)
In article <EMV.91Apr16152546@poe.aa.ox.com>, emv@ox.com (Ed Vielmetti) writes: > In article <1936@crackers.clearpoint.com> martillo@crackers.clearpoint.com (Martillo) writes: >> .... the Cypress Intranet >> Network architecture. ... > > I'm not entirely familiar with Cypress, though I understand that it > has an innovative approach to wide-area networking. Is this Cypress the one originated at Purdue and was used in various places in the Internet a few years ago? The one that CSNET ran with links to decwrl, sgi.com, Arizona, Utah, Purdue, BBN, and a few others? The one CSNET and later Purdue tried to sell as an alternate IP network, similar in spirit to Alternet and PSI years later? That Cypress was an interesting gadget. However, it is less interesting today for several reasons. It was different, having its own routing and layer 3 buried within what looked like a link layer to IP. The Purdue Cypress was not bad, but neither was it enough better. I think I recall being told by its inventor that he felt its claim to fame was that got wide-area IP running with almost no hardware and minimal software. As far as I know, the Purdue Cypress is gone from the Internet. At least the CSNET west coast hubs were based on Proteon routers (or is it Cisco?). The Indiana-California Cypress link disappeared when DEC, Evans and Sutherland, and Silicon Graphics stopped paying for it. The CIC had become less interested in Cypress before Silicon Graphics switched to BARRNet. Disclaimer: In my spare time I ported the Purdue Cypress from its native Sun-BSD to the SVR3-STREAMS Silicon Graphics IRIS and maintained it and the sgi.com link for a couple of years. I actively investigated putting Cypress into the product line. Since then, I've deleted all of the Cypress source from the source trees here and replaced it with a compressing SLIP that has been in the product line for about a year. If I ever again get some spare time, I want to support PPP. Vernon Schryver, vjs@sgi.com
brian@telebit.com (Brian Lloyd) (04/17/91)
In article <1936@crackers.clearpoint.com> martillo@crackers.clearpoint.com (Martillo) writes: >In article <EMV.91Apr12190323@poe.aa.ox.com>, emv@ox.com (Ed Vielmetti) writes: > >After seeing Vielmetti's comment, I reread RFCs 1171 and 1172. This >rereading reinforced my conclusion PPP is rather inelegant I agree, it could be simpler for what it accomplishes >, mostly harmless Again I agree >and not terribly relevant. Here I disagree with you totally. You go on and discuss how many elements of the protocol, such as the attempt to be HDLC compatible, are superfluous. I agree. I also agree that the finite state machine is excessive ornamentation for so simple a protocol. I agree again. From this point I believe that our viewpoints divide. >1) The PPP RFCs suggest no obvious method of billing except perhaps >timed circuit or leased-line billing. While true you seem to forget that much of the Internet makes use of point-to-point links. Billing is not necessarily an issue. Connectivity is. PPP provides a means whereby routers and hosts of dissimilar manufacture may be combined into a network. Until PPP no standardized mechanism existed to do this. >2) The PTTs are ill-disposed to DARPA Internet style computing and all >protocols associated with such networking systems. The PTTs are not building too many networks here in the US. And even if they are "ill-disposed" many people still find them useful and manage to use DARPA Internet style computing and protocols anyway. >3) ISO is committed to a very different architecture of computer >networks than the DARPA Internet uses and association with the DARPA >Internet will prevent any acceptance of such a standard. Prevent acceptance? All of the major router manufacturers support or have announced support for PPP. Quite frankly, there are many people who are more interested in whether something works than in whether it has been blessed by ISO. >Billing is a serious issue because people use packet networks when they >want to be billed on a per-packet basis. But in an internet, who should >be billed? The endpoint or the person who contracts for an intermediate >link. They use packet networks because they want to be billed on a per-packet basis? I prefer to think that they use packet networks because the packet network meets their need as a data transport service. They probably would be just as happy if they were never billed at all :-). >Also IP packets in an internet have no fixed route through a >concatenated network and the medium is unreliable. Concatenated >networks are a big no-no for the PTTs because they allow the possibility >of tail-end hop-off in that packets may hop in and out of public >networks to avoid long distance charges. Such routing is generally >illegal in a large part of the world. Right! You can move your data virtually anywhere. As for legality, there are many parts of the world where it is permitted. >ISO accepts and reflects the needs and preference of the PTTs. I love that one. I may frame it. >In ISO >OSI, the communications subnet contains all the networking logic and >provides end-to-end service to relatively simple end terminals which >take no part in the actual networking logic. The DARPA Internetwork >assumes that the communications subnet might be rather simple (like an >ethernet coaxial cable for example) and that network hosts which could >be relatively powerful computer systems will take part intimately in the >actual logic or routing packets through the network. > >Both models have their domain of application, but even with the frills, >ornamentation and its somewhat antique style, PPP belong more to the >ARPA Internet model than to the ISO OSI model. Who is arguing? >B) Frame Check Sequence > >RFC 1171 p. 7 and p. 8 states the following. > >"The Frame Check Sequence field is normally 16 bits (two octets). By >prior agreement, consenting PPP implementations may use a 32-bit >(four-octet) FCS for improved error detection." > >Actually, if dial-up service is to be permitted, I would argue that in >the interest of convenience for network administrators the type of FCS >should actually be autodetected. In fact, autodetecting the FCS in this >situation is so easy that I have to wonder whether the members of the >IETF who worked on this part of the specification actually had much >experience with implementing this sort of protocol. The RFC's are preliminary. PPP is undergoing evolution. I suspect that what you suggest may actually take place. It has been a topic of discussion amongst PPP developers. >Since PPP is basically a link-level encapsulation with delusions of >grandeur, this protocol is essentially irrelevant for any sort of >sophisticated computer networking via serial links. Please don't tell that to the PPP users who find it quite useful. They may disagree with you. Of course it is a link level encapsulation. That is what it is intended to be. It is also extendable to meet new requirements, such as your suggestion that it somehow provide support for inverse multiplexing. >Generally, transmitting data over serial links requires sophisticated >user-transparent load-sharing over connections, which might be both >packet and circuit connections as well as user-transparent programmed >link and band-width allocation. > >PPP provides no mechanism for such procedures, which is not necessarily >within the purview of PPP anyway. But since the bridge-router boxes at >both ends of the circuits must agree on the implementation of such >procedures, the actual encapsulation specification is basically more >irrelevant to the customer user than the internal bus structure of the >bridge-router box. Sure they must agree. That is what PPP is all about, an encapsulation scheme that ALL the bridge and router manufacturers can agree upon. I would also like to point out that the Telcos in the US will sell you bandwidth in just about any sized chunk you want. You do not really need to combine multiple links of lesser bandwidth to get what you want. >Now it is possible that the IETF expects the bridge-router box at one >end of the link to communicate directly with an end host at the other >end of the link, in which case a bare-minimum lingua franca serial >communications access method has more importance than I would otherwise >ascribe to such a thing, but my market analysis implies that the number >of customers who desire such a configuration is simply too small for >company resources to be devoted to development of a product which >targets this specific need. There are may "leaf" nodes in networks. Please consider point-of-sale applications for example. Other examples might be small satellite computing facilities. Your "market analysis" may imply that this is a small market but ours doesn't. Time will prove one of us right. >Since PPP does not address the question of architecting an IP network >which use multiple serial links, PPP is essentially irrelevant from the >standpoint of a system architect (like me) and from the standpoint of >the customer or network administrator who has an internet which consists >of several networking technologies including serial links. I think that you are definitely missing the boat. When you are archetecting a network and you are using multiple point-to-point links, you can let the IP layer do the work of the network layer. Besides, IP is there to bind your differing networks (even simple point-to-point links) into an internet. >In order to address the question of architecting an IP network which >uses multiple serial links, I have architected into the Little Dipper a >high-performance intranetwork system similar to the Cypress Intranet >Network architecture. Even if both Little Dippers and the boxes of >other vendors both talk PPP, unless the boxes of the other vendors >conform to the Little Dipper intranetwork architecture, the Little >Dipper and these other boxes really will not interwork. Well, if I need to push packets over the Little Dipper network I can implement some interface code that will allow IP datgrams to travel over the Little Dipper network and use it as just one more network in my internetwork. If Little Dipper will accept my IP datagrams and move them on their way toward their destination, great! >The Little Dipper will also support configuring individual serial links >as IP networks as well as half-gateway and half-bridge configuration. >This sort of flexibility, which directly addresses the implementation of >serial IP networks, is probably more desirable than mere PPP (which will >also be present). Basically, if a customer only cares about PPP, and >purchases boxes simply on the basis of conformance to this >specification, this customer will probably have to be content with low >performance serial computer networking. I am quite sure that Little Dipper is very nice. It is also probably proprietary (I appologize if I am incorrect but your posting leads me to belive this). I am not sure that the world really needs more proprietary protocols right now. > >IV) CONCLUSION > > . . . > >The members were afraid that if they produced no documents, >their managements would get upset that the companies had spent >money unnecessarily to send representatives to T1D1. > >People who worked on PPP through the IETF might have a similar interest >in demanding the use of PPP in bridges and routers because otherwise >their managements might wonder why the companies spent money to send >representatives to take part in the IETF deliberations on PPP. > >In the future, I would hope that people who discuss PPP issues would >make clear whether they might be motivated by such an interest. I hate to tell you this but the people who got together to define PPP did not spend tons of money and travel to exotic places to discuss for hours the whichness of the why. They got together to solve a particular problem and discussed it at length via email. Many networking professionals participated on their own time independently of their work. Many of the participants were users rather than vendors. I know most of them and were I they I would be incensed at such an accusation. (Actually I took part in the process myself and I am a little put off by your apparent attitude.) > >Joachim Carlo Santos Martillo Ajami > >The above comments represent my current thoughts as system architect. >They may change as I study issues more deeply and read the comments of >thoughtful critics. The above comments are not product announcements >and are in no way binding on Clearpoint Research Corporation. -- Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@napa.telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333