|
|
ARCHIVE: TCP-IP Distribution List - Archives (1986)
DOCUMENT: TCP-IP Distribution List for September 1986 (154 messages, 75675 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1986/09.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]----------------------------------------------------
Date: Tue, 2-Sep-86 03:18:43 EDT
From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To: mod.protocols.tcp-ip
Subject: Re: Possible DDN to Ethernet or 802.3 Gateway VendorsLet me correct some slight errors in that posting about the Proteon entry: a) Proteon does not yet have a DDN X.25 interface, but hope to have one soon; b) for details please *do not* contact me, but call Proteon at 617-655-3340. Noel -------
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Tue, 2-Sep-86 09:45:00 EDT From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) To: mod.protocols.tcp-ip Subject: How to IP & ARP on 802 Nets
Date: 29 Aug 1986 19:27:12 PDT
From: POSTEL@B.ISI.EDU
Hello.
Hi.
At an ad hoc special session on "IEEE 802 Networks and ARP" held
during the recent TCP Vendors Workshop, an approach to a consistent
way to sent DOD-IP datagrams and other IP related protocols on 802
networks was developed.
[...]
A very quick reading of this and a small amount of knowledge about 802.x
leads me to believe this looks reasonable. The problem I see is "What
happens if ISO blesses DoD IP and then there are two different ways to
talk it?"
The total length of the SAP Header and the SNAP header is 8-octets,
making the 802.2 protocol overhead come out on a nice octet boundary.
Good.
If we can not quickly resolve the issue of the values for K1 and K2,
we will push for the assignment of a sap value (a K1 value) to
indicate "IP related protocols" and do our own multiplexing (much like
that proposed above).
Please don't say "IP related protocols." Only one protocol is IP
related and that is IP. Instead say "Ethernet'1980 related protocols"
which includes Chaos, PUP, XNS, DECnet, etc.
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Wed, 3-SEP-1986 17:20 EDT From: Ronald A. Jarrell <JARRELLRA%VTVAX3.BITNET@WISCVM.WISC.EDU> To: <tcp-ip@sri-nic.arpa> Subject: nsfnet
We plan on hooking to nsfnet in the near future, probably through a sattelite link and an imp. We were going to be running Wollongong's WIN on the Vaxes, but I've been told we are going to have a horrible time with it, that it wouldn't work with out a lot of kluding.. Anyone have suggestions as to a good, full-function, tcpip package to use in this situation? It would need ddn protocol support, and be able to talk to unix flavor systems. Please also mention whether or not it would require new hardware, or if we could share the deuna we currently have for decnet and lat. Also, while I'm thinking of it, anyone have PD or non-PD code for domain support for a VMS system? -Ron
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Tue, 2-Sep-86 14:20:46 EDT From: jas@BRUBECK.PROTEON.COM To: mod.protocols.tcp-ip Subject: Re: How to IP & ARP on 802 Nets
Your K1 (the SNAP SAP) is '01010101' when presented least signifigant bit first. (First bit to the MAC layer first.) For those of us who think in a forward direction, this is '10101010', or 'AA'hex. While SNAP is only a proposal, I beleive it is de-facto real. I understand that certain proprietary network vendors already plan to use it. By the way, "ethernet types" were handed over by Xerox to the IEEE along with the 24-bit address blocks. There is no list available from IEEE of the allocation of either type of block, they consider that proprietary. I have heard rumors that K2 is '0', and that this 24-bit block belongs to Xerox. Are the Xerox people out there who can confirm this? john shriver proteon -------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Tue, 2-Sep-86 14:27:27 EDT From: jas@BRUBECK.PROTEON.COM To: mod.protocols.tcp-ip Subject: Re: How to IP & ARP on 802 Nets
There already was a blessed way to send IP packets over 802.2. The problem was that the powers that be were NEVER going to provide a SAP for ARP, so the IP SAP was useless. Once we had this scheme for ARP, we decided to do IP that way to provide an even-length data-link header, and one the same size as ARP. (DoD Internet is SAP '06'hex.) -------
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Wed, 3 Sep 86 23:45 PDT From: Provan@LLL-MFE.ARPA To: tcp-ip@sri-nic.arpa Subject: re: How to IP & ARP on 802 nets
I have two problems with this scheme. Unfortunately, both are caused by the SNAP, which seems to be the part closest to being fully blessed. The first problem is the 24 bit "organization" code. A 24 bit field seems excessively clumsy. (In the immortal words of 1822, it's "not particularly convenient for anyone.") Not too serious, but it fits well with my solution. The second problem is that this plan works great with 802.2 type 1 headers, but 802.2 type 2 messages add an additional byte to the normal 802.2 header. If the SNAP scheme is unchanged in this situation, we find ourselves with the new ethernet type field shifted back to an odd byte and our IP packet gets out of alignment. Does anyone know what happens to the SNAP in type 2? I don't know if it's feasible to send IP packets over type 2 802.2, but if it is we need to worry about this. I have a solution that solves both of these problems. Instead of a 24 bit organization code, break it into an eight bit unused pad field followed by a 16 bit organization code. (Happily, this field is then aligned to an even byte.) In type 2 802.2 packets, this unused eight bits becomes the second byte of the 802.2 control field, but the other four bytes of the SNAP (two for the organization code and two for the new ethernet type field) remain the same. So the 802.2 header would be the same size (eight bytes) for both type 1 and type 2 packets, rather than have the three byte header for type 1 and the four byte header for type 2 in the currently published protocol. Of course, this assumes we have anything to say about this. Since this doesn't appear to be the case, i guess it's too late to avoid these problems. Looking back on this note, i realize that someone without familiarity with 802.2 might be confused. I think i can lessen the confusion by explaining that 802.2 packets, including these three or four (or eight) byte headers, ride inside 802.3 packets, which have the familiar 14 byte ethernet header, with the ethernet type field replaced by the famous 802.3 length field. While i have the floor, at the TCP workshop, i think i heard twice that 802.3 lengths less than 60 are illegal, and, therefore, fall under the famous ethernet footnote, which says that any illegal lengths can be interpreted however the implementation wants (thus allowing previous ethernet implementations to continue to operate on the same network as 802.3 impelmentations). If i heard correctly, i'd like to point out that this is not correct. Lengths less than 60 are legal in 802.3. In fact, it's the need to express a packet smaller than 60 bytes in a hardware environment which doesn't allow transmission of packets less 60 bytes in length that is the justification for the length field in the first place. (A packet can be padded out to 60 bytes while the true length of the packet is preserved via the length field.) don provan provan@lll-mfe.arpa
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Thu, 4-Sep-86 02:01:55 EDT From: JARRELLRA@VTVAX3.BITNET (Ronald A. Jarrell) To: mod.protocols.tcp-ip Subject: nsfnet
We plan on hooking to nsfnet in the near future, probably through a sattelite link and an imp. We were going to be running Wollongong's WIN on the Vaxes, but I've been told we are going to have a horrible time with it, that it wouldn't work with out a lot of kluding.. Anyone have suggestions as to a good, full-function, tcpip package to use in this situation? It would need ddn protocol support, and be able to talk to unix flavor systems. Please also mention whether or not it would require new hardware, or if we could share the deuna we currently have for decnet and lat. Also, while I'm thinking of it, anyone have PD or non-PD code for domain support for a VMS system? -Ron
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Thu, 4-Sep-86 02:14:56 EDT From: mrose@NRTC-GREMLIN.ARPA (Marshall Rose) To: mod.protocols.tcp-ip Subject: The ISO Development Environment at NRTC
[ multiple appologies for posting this to multiple lists... ]
/mtr
-----
A N N O U N C E M E N T
The first release of the ISO Development Environment at NRTC is
available for distribution. This release is called
ISODE 1.0
This software supports the development of certain kinds of
ISO/CCITT/ECMA protocols and applications.
Here are the details:
- ISODE is not proprietary, but it is not in the public domain.
This was necessary to include a "hold harmless" clause in the
release. The upshot of all this is that anyone can get a
copy of the release and do anything they want with it, but
no one takes any responsibility whatsoever for any (mis)use.
- ISODE runs on native 4.2BSD and SVR2 with an Excelan card
(Future releases will support VAX/VMS and a variant of PC/IP.)
- Current modules include:
TSAP - makes TCP look like TP4
SSAP - ISO BCS session
PSAP - ASN.1 encoding
PEPY - ASN.1 yacc-like facility
RoSAP - ECMA Remote Operations Services
- Although the ISODE is not "supported" per se, it does have a
problem-reporting address, ISO-People@NRTC.NORTHROP.COM. Bug
reports (and fixes) are welcome by the way.
The primary documentation for this release consists of a User's
Manual (approx 150 pages) and a set of UNIX manual pages. The
sources to the User's Manual are in LaTeX format. In addition,
there are a number of notes, papers, and presentations included in
the documentation set, again in either LaTeX or SLiTeX format.
There are two ways to get a distribution:
1. If you can FTP to the ARPA Internet, use anonymous FTP to
louie.udel.edu [10.0.0.96] and retrieve the file portal/isode-1.tar.
This is a tar image (approx 2.0MB). The file portal/isode-1.tar.Z is
the tar image after being run through the compress program (approx 0.8MB).
2. Send a magtape and a self-addressed mailing label to:
Northrop Research and Technology Center
Attn: Automation Sciences Laboratory (0330/T30)
One Research Park
Palos Verdes Peninsula, CA 90274
USA
+1-213/544-5393
We will write the tape in tar format at 1600bpi, and return it with
a copy of the User's manual.
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Thu, 4-Sep-86 02:45:00 EDT From: Provan@LLL-MFE.ARPA To: mod.protocols.tcp-ip Subject: re: How to IP & ARP on 802 nets
I have two problems with this scheme. Unfortunately, both are caused by the SNAP, which seems to be the part closest to being fully blessed. The first problem is the 24 bit "organization" code. A 24 bit field seems excessively clumsy. (In the immortal words of 1822, it's "not particularly convenient for anyone.") Not too serious, but it fits well with my solution. The second problem is that this plan works great with 802.2 type 1 headers, but 802.2 type 2 messages add an additional byte to the normal 802.2 header. If the SNAP scheme is unchanged in this situation, we find ourselves with the new ethernet type field shifted back to an odd byte and our IP packet gets out of alignment. Does anyone know what happens to the SNAP in type 2? I don't know if it's feasible to send IP packets over type 2 802.2, but if it is we need to worry about this. I have a solution that solves both of these problems. Instead of a 24 bit organization code, break it into an eight bit unused pad field followed by a 16 bit organization code. (Happily, this field is then aligned to an even byte.) In type 2 802.2 packets, this unused eight bits becomes the second byte of the 802.2 control field, but the other four bytes of the SNAP (two for the organization code and two for the new ethernet type field) remain the same. So the 802.2 header would be the same size (eight bytes) for both type 1 and type 2 packets, rather than have the three byte header for type 1 and the four byte header for type 2 in the currently published protocol. Of course, this assumes we have anything to say about this. Since this doesn't appear to be the case, i guess it's too late to avoid these problems. Looking back on this note, i realize that someone without familiarity with 802.2 might be confused. I think i can lessen the confusion by explaining that 802.2 packets, including these three or four (or eight) byte headers, ride inside 802.3 packets, which have the familiar 14 byte ethernet header, with the ethernet type field replaced by the famous 802.3 length field. While i have the floor, at the TCP workshop, i think i heard twice that 802.3 lengths less than 60 are illegal, and, therefore, fall under the famous ethernet footnote, which says that any illegal lengths can be interpreted however the implementation wants (thus allowing previous ethernet implementations to continue to operate on the same network as 802.3 impelmentations). If i heard correctly, i'd like to point out that this is not correct. Lengths less than 60 are legal in 802.3. In fact, it's the need to express a packet smaller than 60 bytes in a hardware environment which doesn't allow transmission of packets less 60 bytes in length that is the justification for the length field in the first place. (A packet can be padded out to 60 bytes while the true length of the packet is preserved via the length field.) don provan provan@lll-mfe.arpa
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Thu, 4-Sep-86 05:07:22 EDT From: steve@BRL.ARPA (Stephen Wolff) To: mod.protocols.tcp-ip Subject: Re: nsfnet
I've been told SRI markets a competitive package, but I've lost the reference. Help, someone? -s
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Sep 86 5:07:22 EDT From: Stephen Wolff <steve@BRL.ARPA> To: "Ronald A. Jarrell" <JARRELLRA%VTVAX3.BITNET@wiscvm.wisc.edu> Cc: tcp-ip@sri-nic.arpa Subject: Re: nsfnet
I've been told SRI markets a competitive package, but I've lost the reference. Help, someone? -s
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 4 Sep 1986 06:24-EDT From: CERF@A.ISI.EDU To: JARRELLRA%VTVAX3.BITNET@WISCVM.WISC.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: nsfnet
Ron, without commenting on the Wollongong software, which I am not qualified to express an opinion about since I have not used it nor reviewed its operation in detail, there is a lengthy publication available from the SRI NIC, and also available on line, I believe, listing quite a number of commercial TCP/IP related products. I don't have the book here with me but urge you to investigate via the NIC. Of course, you should get some interesting replies from the TCP-IP distribution list, too. There is only modest support for VMS, as I recall, as the bulk of the implementations stem from the Berkeley UNIX effort (perhaps 50% are derived in that fashion). Vint
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 5 Sep 1986 11:03-PDT From: Mike StJohns <StJohns@SRI-NIC.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: 1822 vs 1822L Survey
I need to know what implementations use what version of the 1822 protocol to talk to their IMPs. If you are an implementer, tell me whether your implementation talks 1822 or 1822L or both. If you have an X25 implementation, I would appreciate knowing about that also. Reply directly to me and I will summarize for the network. Implementers only please.... can you imagine how large my mailbox will be if everyone replied. Thanks, Mike StJohns, DCA B612
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Sep-86 16:03:59 EDT From: klem@BRL.ARPA To: mod.protocols.tcp-ip Subject: (none)
Subject: imprecise DDN X.25 specification? Newsgroups: mod.protocols.tcp-ip Distribution: usa To: tcp-ip@sri-nic.arpa Keywords: DDN X.25 CDC We have a contract with CDC to build and install an interface from a CDC Cyber 750 running NOS to a MILNET IMP. The contractors attended a 3-day TCP/IP Vendor Workshop in Monterey last month. They came away from the meeting with lots of questions. Can anyone answer the concerns that were surfaced at the meeting (see below for the contractor's questions)? ------------------------------------------------------------------------- It was stated that the contractor can be implementing X.25 in agreement with the contract specification, pass the DCA Qualification Test and not be able to communicate with the IMP. This is a result of the imprecise DDN X.25 specification and the incompleteness of the X.25 Qualification Testing. One X.25 issue that was discussed was the X.25/1822 incompatibility on the network. It is our understanding that the government has developed hardware and software solutions and has the situation under control. Other issues that could affect the CDC interface to the IMP include: 1) CDC X.25 does not establish a virtual circuit for each and every local network destination host and corresponding precedence. 2) CDC will provide the destination address to the IMP through the IP header, as opposed to the X.25 header. 3) CDC will not map an IP address into X.25 and vice-versa. Is it true that any or all of the above issues will create problems in the CDC interface with the DDN? --------------------------------------------------------------------------- Thanks, George Klem <klem@brl.arpa>
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Sep 86 16:03:59 EDT From: klem@BRL.ARPA To: tcp-ip@sri-nic.arpa
Subject: imprecise DDN X.25 specification? Newsgroups: mod.protocols.tcp-ip Distribution: usa To: tcp-ip@sri-nic.arpa Keywords: DDN X.25 CDC We have a contract with CDC to build and install an interface from a CDC Cyber 750 running NOS to a MILNET IMP. The contractors attended a 3-day TCP/IP Vendor Workshop in Monterey last month. They came away from the meeting with lots of questions. Can anyone answer the concerns that were surfaced at the meeting (see below for the contractor's questions)? ------------------------------------------------------------------------- It was stated that the contractor can be implementing X.25 in agreement with the contract specification, pass the DCA Qualification Test and not be able to communicate with the IMP. This is a result of the imprecise DDN X.25 specification and the incompleteness of the X.25 Qualification Testing. One X.25 issue that was discussed was the X.25/1822 incompatibility on the network. It is our understanding that the government has developed hardware and software solutions and has the situation under control. Other issues that could affect the CDC interface to the IMP include: 1) CDC X.25 does not establish a virtual circuit for each and every local network destination host and corresponding precedence. 2) CDC will provide the destination address to the IMP through the IP header, as opposed to the X.25 header. 3) CDC will not map an IP address into X.25 and vice-versa. Is it true that any or all of the above issues will create problems in the CDC interface with the DDN? --------------------------------------------------------------------------- Thanks, George Klem <klem@brl.arpa>
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Fri, 5-Sep-86 18:25:31 EDT From: cetron@UTAH-CS.ARPA (Edward J Cetron) To: mod.protocols.tcp-ip Subject: Re: nsfnet
-------------------------- the standard sacrificial line We have been using the Tektronix tcp/ip package for quite a few months and have found it extremely useful... A quick summary: Advantages (especially vs. WIN/VX) 1. you are given ALL of the source code (albeit in bliss) 2. the code is NATIVE-style NOT a unix port 3. it has proved to be very reliable, easy to modify for local hacks/improvements 4. with very few exceptions, it is very clean, readable code which tends to follow the tcp mil-std very well.... 5. with the software tools message system (public domain from lbl) it also will support smtp as per rfc 822, 821.... 6. it is virtually free for an educational institutional site license. Disadvantages: 1. It is available currently only to educational institutions (but some commercial sites HAVE gotten access to it). 2. it currently only supports telnet, ftp, 3com ftp, and smtp 3. there is no support (but then i understand the Wollongong doesn't support there product either in reality) 4. it does not yet support nameservers, >255 hosts, and anything other than in its fixed host table (however; we are currently fixing these problems and hope to have them resolved within 2 months) All in all, compared to WIN/VX (which i HAVE used) i feel that it is infinitely superior (and much cheaper). While it isn't perfect (yet) you have the code to fix whatever ails it. One of our sites has been using it for 3 months with NO MAJOR COMPLAINTS except when the WIN/VX site that they talk to screws up. I would be happy to answer any further questions or supply details if people would like... -ed cetron center for engineering design Univ. of Utah cetron%utah-cbd@utah-cs.arpa
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Sat, 6-Sep-86 05:02:54 EDT From: mckee@MITRE.ARPA To: mod.protocols.tcp-ip Subject: Gateway Selection Procedure
Gentlemen:
I solicit advice and document references on how IP should select a
particular Gateway when more than one is available.
Background
My responsibilities include writing communications and network
performance requirements for a large military system called the WWMCCS
Information System (WIS). The WIS will (initially) consist of about 40
sites. Each site will have:
- a 10 Mbps Applitek LAN
- 2 or 3 large host processors
- 50 to 150 workstations
The workstations and hosts are connected to the LAN through Interface
Units (IUs). TCP and IP are performed in the IUs.
Each LAN has at least one Gateway IU that connects the LAN to the
DDN-RVN (DDN-Red Virtual Network, Class A Net 21). All inter-site
communications use net 21. For increased throughput and availability,
some sites will have 2 or 3 Gateway IUs. Some Gateways will connect to
the DDN-RVN at 56 Kbps, others at 9.6 Kbps.
Each LAN has a LAN Control Center/Security Monitor (CC/SM). For
security and access control, procedures have been established such that
the CC/SM is aware of the status of every connection; every TCP active
or passive open/close/abort request is routed through the CC/SM.
Further, by means of periodic interrogation, the CC/SM knows the health
and traffic load of every local IU, including the local Gateways.
Questions
When IP in a host or workstation IU receives a datagram destined for a
remote site, what procedure should be used to select one of the local
Gateways?
When IP in a Gateway receives a datagram from the LAN, what procedure
should be used to select one of the Gateways at the remote site?
Any advice or references would be appreciated.
H. Craig McKee
'mckee at mitre'
(703)883-5505
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Sun, 7-Sep-86 02:12:37 EDT From: Murray.pa@XEROX.COM To: mod.protocols.tcp-ip Subject: Re: Ethernet between buildings
If you can possibly find the $ for the fibers, that's the way to go. If you talk to anybody in the fiber business, this is probably the first application they will mention. I suggest a very cautious, respectful approach when dealing with things as potent as lightning. You may think your buildings are both grounded but at the currents developed near lightning strikes, all sorts of unobvious things will happen. Consider what will happen when your whole net goes down. You may only have a few machines today, but you know that more be running tomorrow. People will be using them for term projects and writing their thesis. Networks are addicting. Remember that it will happen durning the end of term rush. We have one (coax) ethernet under the street to another building. 6 or 7 years ago, a lightning bolt hit the hill a bit beyond that building. It fried the front end transistor in dozen or so transcievers. Each fried transistor was a short accross the coax. That whole net was down until they found the last dead transciever. There were lots of people milling around the halls and grumbling... (At least we could scrounge enough transcievers on short notice to get everybody back on the air.) (That was a long time ago. A simple resistor in the right place will probably provide enough protection. Most transcievers probably include one now.)
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 7 Sep 1986 05:24-EDT From: CERF@A.ISI.EDU To: mckee@MITRE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Gateway Selection Procedure
Mr. McKee - you should be able to "pick any" of the known available gateways - if you picked the wrong one, relative to minimum delay routing, that one will "redirect" you to the right one. However, it is possible the one you picked is dead. If the subnet you use to reach that gateway tells you about dead hosts, as the ARPANET does, then you will be able to detect this mistake and change your tables to select another gateway. There is no existing algorithm for selectively routing traffic across multiple gateways. Dave Mills tried one that resulted in every other packet landing in the Atlantic Ocean (The "Atlantic Two-Step"). It is not even clear that such bifurcation oftraffic across a single TCP logical connection would be a good idea - especially if the two routes have widely differing delay/loss characteristics - the TCP level performance monitoring and feedback control might have a lot of trouble trying to adapt if every other packet, for instance, went a different way with very different parametric profile. Vint
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 7 Sep 1986 05:40-EDT From: CERF@A.ISI.EDU To: klem@BRL.ARPA Cc: tcp-ip@SRI-NIC.ARPA
Wow! A fast reading of your message, especially the last part characterizing the DCD X.25, suggest you are in trouble. The IMP does NOT, so far as I know, examine the IP for an address. The host or front end doing the IP has to map the internet address into an appropriate X.25 address (to the destination or to the gateway on the X.25 network). It is not necessarily a requirement that each TCP connection be mapped into a distinct X.25 virtual circuit. Some implementations map all TCP connections into a single X.25 virtual circuit between source and destination or source and gateway. This could result in poorer throughput as the number of TCP connections increases and also result in some interference between the varius communicating processes sharing the common virtual circuit. Since there is no easy way to tell IP that it is handling a new TCP connection, this is an area of performance concern which may have implementation and/or application specific consequences and require specific remedies. BBN has developed software which permits 1822 and X.25 interoperability; however, there are two modes of X.25 interface on the network: standard and basic. The basic mode is incapable of dealing with the X.25/1822 mapping since it is really just an end/end X.25 pipe - the commercial interface to X.25 that BBN sells. The Standard mode (DoD standard) will support 1822/X.25 interfacing. ALL of X.25 is terminated in the IMP at the interface. At the destination, if the interface is also Standard X.25 (not BASIC X.25), the full X.25 is RECREATED. If the destination is 1822, it will see a fabricated 1822 exchange. In the STANDARD case, X.25 and 1822 addresses are mapped back and forth. There was indication at the Monterey meeting that the STANDARD X.25 mode had not necessarily been installed on both the ARPANET and MILNET - the DDN NIC would be a good place to query in this regard. The principle issue is whether the typical commercial implementations of X.25 are compatible with (interoperate with) the DoD Standard X.25. They certainly SHOULD interoperate with BASIC X.25. The reason there are two X.25 style interfaces is that the BASIC mode was readily available and permitted hosts with vendor-specific protocols to use the MILNET for communications, independent of interoperability with other hosts on the system. If all hosts used X.25 interfaces, I believe there would be no need for the Standard X.25 interface with its conversion facility - but this is not the case. I'm sure you'll get other comments on the TCP-IP distribution. Maybe we need an RFC laying all this out... Vint
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Sun, 7-Sep-86 17:32:27 EDT From: haverty@CCV.BBN.COM To: mod.protocols.tcp-ip Subject: Re: Gateway Selection Procedure
Vint et al, A minor clarification. There is no general algorithm in use which spreads traffic across multiple gateways. There is however a special-purpose table-driven algorithm in the Arpanet/Milnet mailbridges, which attempts to spread traffic amongst the seven parallel mailbridges. It is effective only for hosts which are physically connected to the Arpanet or Milnet, but not gateways, because hosts listen (should at least) to redirects but gateways do not. Fortunately this covers a lot of the traffic; without this mechanism, the mailbridge would be a highly reliable bottleneck (more so than it is now), since only one path would be "best", with six !! idle backup gateways at any time. Unfortunately, with more LANs all the time, this interim approach is clearly limited. There is a feature in design stages now for the C/30 family, which will permit multipath routing to occur -- i.e., between points A and B several parallel paths might exist, and all might be in use to carry traffic. With such a mechanism, for example, a network with only 9.6 kilobit/sec trunks could achieve a host-host throughput greater than 9.6 by using the multiple paths. This is a very hard problem, to achieve stability and efficiency and avoid behavior like the Atlantic two-step. Jack Haverty
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Sun, 7-Sep-86 18:12:56 EDT From: jas@BRUBECK.PROTEON.COM.UUCP To: mod.protocols.tcp-ip Subject: Re: re: How to IP & ARP on 802 nets
SNAP is not 'our' protocol, any more than 802.2 is ours. We don't have any contorl over it. If we had wanted to avoid this mess, we (sigh) should have been on 802.2. AS I noted, vendors are already using SNAP. The reason that the code is 3 bytes of owner, and two of protocol number, is that they can then use the already-allocated 24-bit prefixes that define 48-bit address blocks. Hey, 48-bits is absurdly long, also. I think that running a datagram network protocol like IP over class 2 802.2 is a non-sequitor, so we don't need to worry about it. I will admit that I can't see how SNAP would work with class 2 at all. In the ISO world, class 1 is used with connectionless internet at the network level, and class 2 with a null network layer. john shriver proteon -------
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Sun, 7 Sep 86 18:12:56 EDT From: jas@brubeck.proteon.com To: Provan@LLL-MFE.ARPA Cc: tcp-ip@sri-nic.arpa Subject: Re: re: How to IP & ARP on 802 nets
SNAP is not 'our' protocol, any more than 802.2 is ours. We don't have any contorl over it. If we had wanted to avoid this mess, we (sigh) should have been on 802.2. AS I noted, vendors are already using SNAP. The reason that the code is 3 bytes of owner, and two of protocol number, is that they can then use the already-allocated 24-bit prefixes that define 48-bit address blocks. Hey, 48-bits is absurdly long, also. I think that running a datagram network protocol like IP over class 2 802.2 is a non-sequitor, so we don't need to worry about it. I will admit that I can't see how SNAP would work with class 2 at all. In the ISO world, class 1 is used with connectionless internet at the network level, and class 2 with a null network layer. john shriver proteon -------
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Mon, 8-Sep-86 11:30:43 EDT From: JNC@XX.LCS.MIT.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Gateway Selection Procedure
The answer to the first question you ask is contained in two RFC's in the TCP/IP guide; I don't remember which volume they are in in the white books, but they are RFC's 814 and 816, "Names, Addresses, Ports and Routes", and "Fault Isolation and Recovery". I don't want to sound like a broken record, but I wish people would read the documentation provided before asking questions. I am aware that those books contain a lot of material: perhaps the NIC could include a 'Suggested Readings' list in the next printing which would list RFC's 813-817 as 'Required'? The second question is sort of covered by RFC's 904 and 888, which describe the current Internet model for routing packets among gateways. Noel -------
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Mon, 8-Sep-86 16:48:00 EDT From: MAB@CORNELLC.BITNET.UUCP To: mod.protocols.tcp-ip Subject: Anybody Have Code for an Echo Host?
At the TCP/IP Vendor's Workshop in Monterey, mention was made of a beast
called an "Echo Host". As I understand it, this is a tool for shaking out
a host implementation of TCP/IP. It simply echoes IP datagrams, with
controls for delay, bandwidth, and error rate.
Does anyone have code for an Echo Host? In particular for an IBM PC?
Also, mention was made at the workshop of the existence of a How-To-
Build-An-Echo-Host RFC. I can't find it - can someone tell me the number?
My Internet address is:
mab%cornellc.bitnet@wiscvm.wisc.edu
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Mon, 8 Sep 1986 16:48 EDT From: Mark Bodenstein <MAB%CORNELLC.BITNET@WISCVM.WISC.EDU> To: <tcp-ip@sri-nic.arpa> Subject: Anybody Have Code for an Echo Host?
At the TCP/IP Vendor's Workshop in Monterey, mention was made of a beast
called an "Echo Host". As I understand it, this is a tool for shaking out
a host implementation of TCP/IP. It simply echoes IP datagrams, with
controls for delay, bandwidth, and error rate.
Does anyone have code for an Echo Host? In particular for an IBM PC?
Also, mention was made at the workshop of the existence of a How-To-
Build-An-Echo-Host RFC. I can't find it - can someone tell me the number?
My Internet address is:
mab%cornellc.bitnet@wiscvm.wisc.edu
-----------[000026][next][prev][last][first]----------------------------------------------------
Date: Mon, 8-Sep-86 20:17:38 EDT
From: MDCG.HRD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU ("Hank R. "Jim" Dixon")
To: mod.protocols.tcp-ip
Subject: X25 implementations
Hello, does anybody happen to know about any exsisting implkementations
for X25 on the VAX under either VMS (preferably) or UNIX?? Thank you.
JIM
-------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Mon, 8-Sep-86 20:44:04 EDT From: lekash@AMES-NASB.ARPA (John Lekashman) To: mod.protocols.tcp-ip Subject: hyperchannel and IP
Hi there. two things: 1. I've been doing some work on an NSC hyperchannel device driver. I started with what was working on 4.2, and with help from Mike Karels at Berkeley, have got it working on 4.3 unix. Its available on ames-nasb in /usr/ftp, including 4.3 kernel changes, (to support raw access) cray research's cxint (yuk!) and hyroute (also yuk!) 2. While getting this working, I found many things about how it functions in need of repair or improvement. I am interested in starting a mailing list of people who use hyperchannels on IP nets. I want to see some sort of standard about encapsulation, routing, and raw access. We spent a great deal of time wretching about all sorts of things here, and finally everyone just copied what cray research had given us, since getting them to change was the hardest. If no one else is currently running such a list, I will. I have created hy-people, and hy-people-request at ames-nasb.arpa (orville). thank you, john
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Sep-86 06:55:22 EDT From: cel@MITRE-BEDFORD.ARPA To: mod.protocols.tcp-ip Subject: NETBIOS ISSUE---TCP Handoffs
At the NETBIOS-TCP/IP Interface Specification Forum held Aug 28 in
Monterey, CA two proposals were discussed. A major issue revolved around the
capability of some operating systems to support handoff of TCP connections
from one process to another.
Are there problems in handing a TCP connection from one process to
another for some operating systems? Which operating systems have difficulty?
Please mail comments to netbios@mitre-bedford.arpa.
The problem in the context of the NETBIOS issue is described below.
Assume two hosts, one contains a client application program and the
other contains a server application program. the problem is to establish a
session between the programs (message oriented, no loss or duplication). The
hosts contain NETBIOS agents for their respective application programs to
interpret the various NETBIOS commands. Also assume that the
server host contains a NETBIOS validation program that verifies if two NETBIOS
named application programs may communicate. Exchanges may occur between the
client and validation programs via UDP messages as in proposal one or over a
TCP connection as another proposal. Data passed over a session between
application programs occurs over a TCP connection.
One proposal (figure A below) calls for passing all session control
information via UDP messages between the NETBIOS client program located in the
source host and the NETBIOS validation program in the destination host.
The NETBIOS Name service has provided the IP address of the server host.
The validation pgm is accessed through a TCP well known port (wkp). If the
session is valid (a server application has posted a NETBIOS listen for c-name)
then the server program does a fully specified TCP passive open using s-port,
c-port and the IP addresses. The client program then establishes a TCP
connection to the server program using s-port, c-port, and the IP addresses.
No handoff of a TCP connection between the validation program and the server
program is required.
Figure A: NETBIOS Names Passed via UDP
CLIENT SERVER
Validation pgm does
UDP(c-name, s-name, c-port)-------> UDP wkp listen to any
(timeout)
agent pgm does TCP
<--------------UDP(s-port)--------- fully spec passive
open on s-port,c-port
(timeout)
TCP(s-port) SYN ------------------> TCP conn established
to NETBIOS agent
<---------------------SYN---------
<-------------data---------------->
etc.
Another proposal (figure B below) calls for the client to determine
the server's TCP port (s-port) via the NETBIOS Name service. Meanwhile the
NETBIOS validation program posted a TCP partially specified passive open (ppo)
open on s-port due to a NETBIOS LISTEN issued by an application program. The
client program then establishes a TCP connection to the client validation
program and passes session control information (c-name,s-name) over the
connection. If the session is valid between the two NETBIOS named
applications, then the TCP connection is handed off to the server agent
program. If the session is rejected then the TCP connection is broken.
Figure B: NETBIOS Names Passed via TCP Connection
CLIENT SERVER
Validation pgm does
TCP ppo on s-port
TCP(s-port) SYN----------------->
<---------------------------SYN--
------data(c-name, s-name)------> Validate and handoff
TCP conn to server
agent pgm
(timeout)
<----------data(ack, nack)-------
<----------data----------------->
etc.
Thanks, ---- Lee LaBarre
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 9 Sep 1986 08:23-EDT From: CERF@A.ISI.EDU To: MDCG.HRD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Cc: tcp-ip@SRI-NIC.ARPA, jsol%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Subject: Re: X25 implementations
Digital has a package called PSI (Version 4.0) which allows VMS to make use of X.25 networks. Vint Cerf
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 9 Sep 1986 08:37-EDT From: CERF@A.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Subject: Formatting Query
I apologize for the broadcast, but I wonder if I am the only recipient of TCP-IP distribution list messages troubled by receipt of messages containing naked horizontal tabs (control-I characters)? It is generally difficult to properly reconstruct the tab settings for presentation. If this is not just a local problem, perhaps we could agree to expand tabs before submitting messages to TCP-IP distribution to improve matters until someday we have a common document representation format which can include adivce about tab settings automatically. I recognize that such a proposal runs the risk of increasing the total length of messages but perhaps this is a small price to pay for improved communication. Is anyone else out there having similar difficulties? Vint Cerf
-----------[000031][next][prev][last][first]----------------------------------------------------
Date: Tue, 9-Sep-86 14:40:29 EDT
From: ahill@CC7.BBN.COM ("Alan R. Hill")
To: mod.protocols.tcp-ip
Subject: re: imprecise DDN X.25 specification?George, As Dr. Cerf already pointed out, the concerns you have are valid and will definitely affect the ability of the CDC interface to communicate with the DDN Standard Service. I cannot comment on the relationship between DCA Qualification and an ability to communicate effectively using the DDN but I can offer some information on what the BBN packet switch does during use of Standard Service. Standard Service will process an X.25 call by removing its X.25 transport envelope and using the contents to generate an 1822L envelope. Standard Service allows only one VC per triplet of <source address>, <destination address>, and <precedence>. Unfortunately, I believe each of your issues will prevent communication with the DDN. I would like to hear suggestions about areas for improvements in the specification or the DCA Qualification. Alan
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Tue, 9 Sep 86 14:40:29 EDT From: "Alan R. Hill" <ahill@cc7.bbn.com> To: klem@brl.arpa Cc: tcp-ip@sri-nic.arpa Subject: re: imprecise DDN X.25 specification?
George, As Dr. Cerf already pointed out, the concerns you have are valid and will definitely affect the ability of the CDC interface to communicate with the DDN Standard Service. I cannot comment on the relationship between DCA Qualification and an ability to communicate effectively using the DDN but I can offer some information on what the BBN packet switch does during use of Standard Service. Standard Service will process an X.25 call by removing its X.25 transport envelope and using the contents to generate an 1822L envelope. Standard Service allows only one VC per triplet of <source address>, <destination address>, and <precedence>. Unfortunately, I believe each of your issues will prevent communication with the DDN. I would like to hear suggestions about areas for improvements in the specification or the DCA Qualification. Alan
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Sep-86 20:22:26 EDT From: mike@BRL.ARPA (Mike Muuss) To: mod.protocols.tcp-ip Subject: Re: Formatting Query
I though there was general agreement that tab stops were every 8 characters? I don't know if this is official NETASCII, but since TOPS-20, UNIX, and VMS all do it this way, most systems go along. -Mike
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Tue, 9-Sep-86 21:03:57 EDT From: jcp@BRL.ARPA (Joe Pistritto, JHU|mike) To: mod.protocols.tcp-ip Subject: VMS TCP/IP over Ethernet?
I'm working on upgrading a site that currently runs VMS on its Vaxen to running 4.3 (at least most of the time), and the issue of communications has come up. Presently, there is nothing, so the slate is clean. I'm thinking of getting some of the Interlan (MICOM) smart ethernet controllers, and running their VMS TCP/IP package on one machine, with 4.3 on the others. Has anyone else come up against the problem of needing hardware that is both VMS and UNIX compatable, (so that either machine can be used for either system), and found a better (more cost effective) solution? The Interlan folks claim to have FTP and TELNET implemented under VMS, I have also checked out Wollongong, any others out there I've missed? Were not Government or educational, so I don't think the Tektronix code is available. -JCP-
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Wed, 10-Sep-86 08:34:24 EDT From: MRC@SIMTEL20.ARPA (Mark Crispin) To: mod.protocols.tcp-ip Subject: Re: Formatting Query
Vint -
So far as I know Multics is the only operating system in common use
on the Internet which does not use tab stops at every 8th character. My
experience suggests that it is basically hopeless in a true heterogenous
environment to use tab stops at any other position due to the large number
of terminals which do not offer settable tab stops.
I admit that "8 tabs" are hopelessly hacker oriented and probably
aren't santioned by any standard, but c'est la vie. Many of the Internet
protocols are hopelessly hacker oriented. I'm sure ISO will "improve"
this situation; I have no way of telling if ISO will do anything to improve
it though.
If you read your mail at A.ISI.EDU (as opposed to having some agent
pick it up and pass it on to your real mailbox), you should know that
A.ISI.EDU is a TOPS-20 system and TOPS-20 uses 8 tabs exclusively. Tenex
had programmable tabs, but this functionality was deleted in TOPS-20.
Therefore, it is correct that any terminal connected to a TOPS-20 system
should use 8 tabs. I think the same is true for Unix and VAX/VMS. If
not I'm sure I'll receive 1000 messages telling me what an idiot I am...
-- Mark --
-------
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Wed, 10-Sep-86 15:51:05 EDT From: AI.CLIVE@MCC.COM (Clive Dawson) To: mod.protocols.tcp-ip Subject: DELNI Strangeness
Here's a bit of info to add to the general folklore: We moved to a new building last week, and after putting everything back together, we found that TELNET connections from our Sun workstations to our DEC-20 (they're on separate Ethernets, gateway is a Sun) were suffering from horribly poor throughput. Echo delays ranged from 1 to 10 seconds, with no load to speak of on any of the systems or the nets. After being stumped for a couple of days, we finally realized that the only thing that had changed was that the Sun gateway and the DEC-20 were now sharing the same DELNI, whereas before they had been on two different DELNIs. We made a quick switch and put the Sun onto its own transceiver two meters away from the DELNI's transceiver. The results were immediate and dramatic. Echoing delays disappeared completely and users were once again happy. Now the obvious question: Does anybody have an explanation? Is there something fundamentally different about intra-DELNI communication that could cause such enormous performance problems? Thanks, Clive -------
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Wed, 10-Sep-86 16:38:21 EDT From: cel@MITRE-BEDFORD.ARPA To: mod.protocols.tcp-ip Subject: Postponement of NETBIOS Meeting
The NETBIOS meeting scheduled for Sept 29 at Stanford has been postponed. A new meeting date has yet to be selected. The package containing the proposals, slide copies and issue discussions is still being prepared. It will be sent to the participants of the Aug 28 meeting in Monterey, CA. Lee LaBarre
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Wed, 10-Sep-86 20:19:17 EDT From: mike@BRL.ARPA (Mike Muuss) To: mod.protocols.tcp-ip Subject: Re: VMS TCP/IP over Ethernet?
For VMS, also consider the Excelan board in smart mode, and maybe the CMC people have a VMS offering too? -M
-----------[000039][next][prev][last][first]----------------------------------------------------
Date: Thu, 11-Sep-86 06:57:00 EDT
From: Walker@RADC-MULTICS.ARPA ("Robert K. Walker 'Bob'")
To: mod.protocols.tcp-ip
Subject: Re: Formatting Query
Date: 9 September 1986 20:22 edt
From: Mike Muuss <mike at BRL>
Subject: Re: Formatting Query
I though there was general agreement that tab stops were every 8 characters?
I don't know if this is official NETASCII, but since TOPS-20, UNIX, and VMS
all do it this way, most systems go along.
-Mike
Tab stops every 8 characters may be the convention for DEC equipment,
which was what was mentioned. However, the Multics convention is every
10 characters. I have FTP'ed files from DEC machines with the tab codes
present, only to get a very ragged looking format when it is
interpretted by Multics. This is a nuisance.
-Bob Walker-
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Thu, 11-Sep-86 11:20:14 EDT From: cel@MITRE-BEDFORD.ARPA To: mod.protocols.tcp-ip Subject: NETBIOS ISSUES -- Datagram service
At the Aug 28 NETBIOS meeting in Monterey, CA two proposals for
implementing NETBIOS on TCP/IP were discussed. One of the areas in which
these proposals differ pertained to the NETBIOS datagram service. The essence
of the differences relative to this area is outlined below. We would
appreciate your comments about the relative merits and implementation
feasibility/difficulty of the alternative proposals to accomplish datagram
service. Please send your comments to:
netbios@mitre-bedford.arpa
(NOTE: In both proposals IP datagrams are not broadcast out on the
internet, i.e. WAN.)
First Proposal
a) Use NETBIOS Name service to discover target UDP port and IP address
Since a name cache is assumed to be at each node, only infrequently
would name queries result in traffic on the channel.
b) Datagrams sent to a unique name are sent as directed UDP datagrams
with control info and data contained within.
c) Datagrams sent to a group name or broadcast use IP subnet broadcast
Second Proposal
a) All NETBIOS datagrams would be IP subnet broadcast UDP datagrams.
No name lookup is required.
b) UDP datagrams would contain control info and data
ISSUES
1. Is the first proposal's assumption of a name cache good? (note:
IBM's PC Network uses a cache at each node)
NOTE: If a name cache is not used then each NETBIOS datagram would
result in a broadcast name query, one or more responses and
the directed UDP containing the NETBIOS datagram. All hosts
would have to process the name query.
2. Proposal two would require all hosts on the subnet to process the
IP datagrams - even those not using NETBIOS. The assumption here
is that the NETBIOS datagram service is infrequently used and thus
hosts that are not the intended recipient would not be overly
burdened.
Is infrequent use of directed NETBIOS datagrams a good assumption?
Are slow listeners going to miss datagrams?
Thanks --- Lee LaBarre
-----------[000041][next][prev][last][first]----------------------------------------------------
Date: Thu, 11-Sep-86 12:09:00 EDT
From: Ata@RADC-MULTICS.ARPA ("John G. Ata")
To: mod.protocols.tcp-ip
Subject: Re: Formatting Query
I think the point is being missed here with regard to tab
stops. If everyone on the network interpreted tabs the same way, this
transaction would never have been started. Since there is variation on
tab interpretation, it would seem that if the SMTP mailers expanded the
tabs to the appropiate number of spaces, then compatability would be
assured. The only negative effect of this might be to people who FTP
files via mail, and who might not get exactly the same file on the other
side. However, they might wish to to use FTP instead...
John G. Ata
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Thu, 11-Sep-86 14:37:16 EDT From: jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes) To: mod.protocols.tcp-ip Subject: Re: Formatting Query
From: "John G. Ata" <Ata@RADC-MULTICS.ARPA>
Since there is variation on tab interpretation, it would seem
that if the SMTP mailers expanded the tabs to the appropiate
number of spaces, then compatability would be assured.
Wow, did this come out of left field or am I really missing
something? I don't really think you want to do this ...
/jordan
ps: maybe a better way of looking at tabs is like those stupid vt100
escape sequences that lock up my terminal, but give an vt100'er
double width characters ...
pss: all you UNIX'ers out there using Mail can do a ~|expand just before
hitting ^D to end your message ... I did this for this message --
how does it look to you Multics'ers?
-----------[000043][next][prev][last][first]----------------------------------------------------
Date: Thu, 11-Sep-86 15:20:00 EDT
From: JSLove@MIT-MULTICS.ARPA ("J. Spencer Love")
To: mod.protocols.tcp-ip
Subject: Multics TABsAre, as several have noted, every 10 columns. It is the position of the Multics mailer developers that TAB characters should never be sent over the network, since there is no "standard" width. Thus, all outgoing mail is detabbified, at some slight cost in network throughput. Mail coming in is also detabbified, which affects only non-Multics mail, since there are no tabs in mail leaving Multics. This detabbification *ought* to assume tabs every 8 columns, since this is the de-facto standard. That it doesn't is a bug (to be fair, if the mailer developer had agreed with me, this problem would never have arisen). None of this helps FTP users, since FTP does no TAB transformations. There is, however, a Multics command, "canonicalize", which can insert and remove TAB characters assuming any TAB width, which helps out in some situations. There are other TAB widths in use. I think that Magic 6 uses (used?) a width of 5. The width of 8 is pretty consistent across DEC equipment, but there are other manufacturers out there. There didn't seem to be any consistent use of TABs at all in IBM program products, last I checked. Anyone out there using non-DEC and non-Honeywell gear?
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Thu, 11-Sep-86 15:35:08 EDT From: ROODE%BIONET@SUMEX-AIM.STANFORD.EDU (David Roode) To: mod.protocols.tcp-ip Subject: DELNI characteristics
We have noticed that DELNI's have some non-intuitive limitations on cable length. Could this perhaps have some bearing on your problem? Unlike other multiport transceivers, the rule for DELNI's is that the transceiver cable length limitation of 40m (vs. 50m for other devices) applies to the sum of lengths of the drop to the DELNI and the drop from the DELNI to the host system. It is also against the rules to plug one DELNI into another one unless that DELNI is NOT connected to an Ether. -------
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Thu, 11-Sep-86 19:58:36 EDT From: leong@andrew.cmu.edu (John Leong) To: mod.protocols.tcp-ip Subject: Re: DELNI Strangeness
Clive, I don't really know what specifically is your problem with the DELNI. However, one thing you may care to check is this : The DELNI (and for that matter, almost all multiport tranceiver in the market) does not handle "heart beat" correctly. For all practical purposes, heart beat is a kind of acknowledgment from the tranceiver to the station. Within a very short period of time after the tranceiver finished sending the packet into the coax cable, it issue a heart beat signal on the collision pairs of the tranceiver cable - essentially saying "all's well". In the case of the DELNI, this signal is (mistakenly) fanned out to ALL attached stations. The station doing the transmit will know it is a heart beat. However, the other attached stations will treat it as an asynchonous collision notification. Most station will ignore it but I don't know about the DEC-20. However, definitely, do not attached a repeater to a DELNI. Repeater will not toss away heart beat. It will act on it and generate collision reinforcement (jam) on the other side!!! The result is excessive collisions. Very bad news to the overall band width availability. John Leong .
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Sep 86 11:19:57 CDT From: Phil Howard <PHIL%UIUCVMD.BITNET@WISCVM.WISC.EDU> To: TCP/IP List <TCP-IP@SRI-NIC.ARPA> Subject: Tabs every 8 positions
Gee, even IBM has acknowledged that tabs belong on every 8 positions. In VM/SP/CMS's XEDIT is the EXPAND subcommand that expands out the tabs to proper positions. There is also COMPRESS with puts tabs in, and in the proper place. I use these commands to handle files received from non-IBM systems with tabs. Everything has worked out fine. Now I just need a way to get square brackets on my IBM 3178 keyboard.
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Fri, 12-Sep-86 11:32:05 EDT From: jtw@mitre-bedford.ARPA (Welch) To: mod.protocols.tcp-ip Subject: RFC 912, Auth Service
I am interested in finding out whether anyone has either implemented or has comments on the authentication protocol outlined in RFC 912, "Authentication Service". Any pointers or info would be appreciated. Jim Welch jtw@mitre-bedford
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Sep 86 11:48:14 EDT From: hurf@tcgould.tn.cornell.edu (Hurf Sheldon) To: mod.protocols.tcp-ip,,arpa.protocols.tcp-ip Subject: Ultrix1.2 to HPUX problem
We recently connected a VaxstationII & an HP9000/300 via a delni
& after getting the uvax setup correctly we then used the network setup
program on the HP to set it up. What we get now is complete access from the
HP to the uvax but from the uvax to the HP we get "connection refused"
under telnet & just "time outs" on ftp & rlogin. We have set up the host tables
on the uvax for some more HP's not yet connected & when we try to go to them
we get a "host unreachable" so we believe the HP is recognizing it's address
correctly but won't answer.
We have Ultrix1.2 on the uvax & HPUX on the HP. The uvax is set
"broadcast -trailers netmask 0xffffff00" - must be set this way to conform
to local cornell net standards.
Any & all suggestions appreciated.
Hurf Sheldon Arpa.css: Hurf@ionvax.tn.cornell.edu
Lab of Plasma Studies
369 Upson Hall phone: 607 255 7267
Cornell University
Ithaca, N.Y. 14853
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Sep 86 11:54:36 EDT From: hurf@tcgould.tn.cornell.edu (Hurf Sheldon) To: arpa.tcp-ip Subject: Ultrix to HPUX problems
We recently connected a VaxstationII & an HP9000/300 via a delni
& after getting the uvax setup correctly we then used the network setup
program on the HP to set it up. What we get now is complete access from the
HP to the uvax but from the uvax to the HP we get "connection refused"
under telnet & just "time outs" on ftp & rlogin. We have set up the host
tables on the uvax for some more HP's not yet connected & when we try to
go to them we get a "host unreachable" so we believe the HP is recognizing
it's address correctly but won't answer.
We have Ultrix1.2 on the uvax & HPUX on the HP. The uvax is set
"broadcast -trailers netmask 0xffffff00" - must be set this way to conform
to local cornell net standards.
Any & all suggestions appreciated.
Hurf Sheldon Arpa.css: Hurf@ionvax.tn.cornell.edu
Lab of Plasma Studies
369 Upson Hall phone: 607 255 7267
Cornell University
Ithaca, N.Y. 14853
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Fri, 12-Sep-86 11:58:00 EDT From: Chartoff@DDN2.ARPA To: mod.protocols.tcp-ip Subject: DECNET
I am looking for interface products that would allow DECNET communication across the Arpanet/Milnet or a public data network (PDN). Has anyone had experience with such products and want to give advice? Thanks
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 12 Sep 86 11:58 EDT From: Chartoff @ DDN2 To: tcp-ip @ sri-nic.arpa Cc: Chartoff @ DDN2 Subject: DECNET
I am looking for interface products that would allow DECNET communication across the Arpanet/Milnet or a public data network (PDN). Has anyone had experience with such products and want to give advice? Thanks
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Fri, 12-Sep-86 12:19:57 EDT From: PHIL@UIUCVMD.BITNET (Phil Howard) To: mod.protocols.tcp-ip Subject: Tabs every 8 positions
Gee, even IBM has acknowledged that tabs belong on every 8 positions. In VM/SP/CMS's XEDIT is the EXPAND subcommand that expands out the tabs to proper positions. There is also COMPRESS with puts tabs in, and in the proper place. I use these commands to handle files received from non-IBM systems with tabs. Everything has worked out fine. Now I just need a way to get square brackets on my IBM 3178 keyboard.
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Fri, 12-Sep-86 12:48:21 EDT From: cetron@UTAH-CS.ARPA (Edward J Cetron) To: mod.protocols.tcp-ip Subject: Re: DELNI characteristics
David Roode writes: >It is also against the rules to plug one DELNI into another one >unless that DELNI is NOT connected to an Ether[net]. WRONG!!!!!!!!!!!!!!!! Nowhere does it say that one DELNI cannot be cascaded to another ethernet connected DELNI! And I've check every manual, tech and sales, Digital has produced.... The above is a very common misconception...the real configuration rule has to do with the fact the propagation delays build through the ethernet having to do with things like cable lengths, numbers of repeaters etc.... The one rule that is most apropos is the 'no more than two repeaters between any two nodes....' This is (among other things) to prevent the propagation delay between any two nodes to be less than the max... For very conservative purposes, the DELNI acts with a propagation delay of 1 repeater and this sort of implies the above misconception. In reality: 1. A DELNI actually appears to introduce the delay of about .6-.7 that of a repeater. 2. I have seen systems with 2, 3, and 4 cascaded DELNI's that work and DO maintain in-spec propagation delays. 3. It has been pointed out that with the appropriate configuration, one could even make 4 repeaters in a row work. 4. The configuration rules (like the rs232 max line length rules) are very conservative to allow 100% probability of a network working when they are strictly adhered to. This means that quite often, for networks not in a very critical area (i.e. hospital ICU's controlling patient therapy) they are only to be considered guidelines BY PEOPLE WHO UNDERSTAND WHY THE RULES ARE THERE. Rules are there for a reason, but should be tested and verified before blindly obeying them without knowing why -ed cetron Center for Engineering Design Univ of Utah cetron%utah-cbd@utah-cs.arpa
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Fri, 12-Sep-86 12:49:01 EDT From: root@BU-CS.BU.EDU (Ra) To: mod.protocols.tcp-ip Subject: Re: Formatting Query
To add my 2c: 1. I am not sure about the definition of "commonly used" but IBM Mainframes (EBCDIC) generally do not interpret tabs the way full-duplex systems use them (not that you can't simulate them, but it tends to be more variable in interpretation, if at all, software application dependant.) 2. Sending files through mail via heterogenous systems is fraught with peril although it usually works well enough if it's just text meant to be used as text (eg. a fortran program with embedded tabs may not compile at all when sent to an IBM system, I don't remember for sure, but I wouldn't be in the slightest bit shocked, and fixing it wouldn't take that much sophistication on the part of the user.) A solution is the UUENCODE/UUDECODE program distributed with UNIX (there are public domain versions) which encodes files in a very conservative way (more or less 026 character subset, 40 chars/line.) For example, I have a version of it running on our IBM mainframe and it seems to work, particularly for cases as above (yes, I expand tabs to every eight, perhaps that should be an option, but at least it's all at the user level rather than a decision made by the SMTP daemon.) Obviously with binary files there's not much you can do, but you could pass one THROUGH an incompatible system with little risk of problems using an encoding, hey, caveat usor.) In re SMTP, I would vote conservative, change nothing unless you have a good reason to (eg. ASCII->EBCDIC, there is an EBCDIC tab character.) It should be easy enough to provide software to do minor conversions once the the file has arrived (if it is intact, expanding tabs for example discards information which seems to violate some basic principle of design.) -Barry Shein, Boston University
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Fri, 12-Sep-86 16:49:00 EDT From: Kevin_Crowston@XV.MIT.EDU To: mod.protocols.tcp-ip Subject: Re: Formatting Query
Just to add to the confusion... My system (a Xerox Star) displays mail in a proportionally spaced font, making all diagrams hard to read without changing the font. I'm not sure if this is a bug or a feature, however. In general, I think that having the mailer expand the tabs would be a bad idea. There might be reasons for wanting the tabs in the message and it shouldn't be impossible to do this. The user mail agent might do that sort of processing by default, however. For example, if I try to send a message that includes font changes, etc. the mailer asks if I really want to send formatted text, and strips the formatting if I don't. Kevin Crowston MIT Sloan School of Management kevin@xv.mit.edu
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 13 Sep 1986 18:37-PDT From: STJOHNS@SRI-NIC.ARPA To: jtw@MITRE-BEDFORD.ARPA Cc: tcp-ip@SRI-NIC.ARPA, sra@MITRE-BEDFORD.ARPA tgw@MITRE-BEDFORD.ARPA Subject: Re: RFC 912, Auth Service
Speaking as the author of rfc912 (actually, see rfc931 which is a revised version of 912) I know of no one who currently implements it. I did a test implementation of it for Multics and did a little playing with implementing the services end of it (i.e. TELNET without having to explicitly login), but that version is lost to obscurity. Mike
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Sat, 13-Sep-86 16:56:42 EDT From: PALLAS@SUSHI.STANFORD.EDU (Joseph I. Pallas) To: mod.protocols.tcp-ip Subject: Re: Formatting Query
RFC821 says:
The mail data may contain any of the 128 ASCII character
codes.
This clearly makes it illegal for SMTP mailers to expand tabs. On the
other hand, RFC822 says:
Writers of mail-sending (i.e., header-generating) programs
should realize that there is no network-wide definition of the
effect of ASCII HT (horizontal-tab) characters on the appear-
ance of text at another network host; therefore, the use of
tabs in message headers, though permitted, is discouraged.
This clearly suggests that mail-agents expand tabs before submitting
them to mailers.
Meanwhile, if you use tabs in formatting such that the width of a tab
stop affects the content of your message (e.g., in drawing pictures),
other people will get what you deserve.
joe
-------
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Sun, 14-Sep-86 12:21:56 EDT From: hedrick@topaz.rutgers.edu (Charles Hedrick) To: mod.protocols.tcp-ip Subject: Re: RFC 912, Auth Service
We implemented RFC 912 on our DEC-20's. Our DEC-20 FTP supports the equivalent of Unix's .rhosts file, and uses auth service to verify that the guy at the other end is really who he claims to be. I regard this is slightly more secure than the mechanism used by rcp.
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Sep 86 08:05:48 MDT From: ncc!lyndon%ALBERTA%UQV-MTS%UMich-MTS.Mailnet@MIT-MULTICS.ARPA To: tcp-ip@SRI-NIC.ARPA, sri-nic.arpa!tcp-ip@ALBERTA
From: lyndon@ncc.UUCP (Lyndon Nerenberg)
Newsgroups: net.video,mod.protocols.tcp-ip
Subject: Re: Ethernet between buildings
Message-ID: <722@ncc.UUCP>
Date: Sat, 13-Sep-86 19:32:57 MDT
References: <611.rbbb.titan@Rice>
Organization: Nexus Computing Corp., Edmonton, AB
Lines: 35
Summary: Not a wives tale!
I am cross-posting as this sort of relates to the discussion in
mod.protocols.tcp-ip about grounding ethernet cables...
In article <611.rbbb.titan@Rice>, rbbb@rice.edu (David Chase) writes:
> ... A sort of old wives tale of lightning protection says that you
> should put a tight loop in a wire near a good ground; the lightning sees
> that as a great big inductor, and hops over to the good ground.
>
> David
The "signal" introduced into a cable by a lightning strike consists of
extremely high frequency radiation. It does not take much inductance to
throw up a "brick wall" to it. Many television stations run their feeds
through a single loop at the base of the tower, then to the transmitter
shack. The RF from a lightning strike will (hopefully :-) take the easier
path from the feed line, through the base of the tower, to ground.
I handled the transmitter plant installation and setup for a local FM BCST
station a couple of years back. The antenna was located on top of a
building at the University. We were unable to properly ground the tower,
so we threw up a loop inside the roof house for the elevators ( *lots*
of metal in there :-)
I know a number of amateur radio op's in town who do the same thing - 2
turns of the feedline at the base (approx. 3 feet in diameter) before
entering the house. I can't say that any of them have been hit, so I won't
guarantee results. Then again, I have watched local TV broadcast towers take
direct hits without going off the air.
I'm sure a posting to net.ham-radio would provide some further information
on practical experiences of dealing with lightning hits.
--
Lyndon Nerenberg (VE6BBM) {ihnp4,ubc-vision}!alberta!ncc!lyndon
Systems Group - A Div. of Nexus Computing Corp. Envoy_100: Unix
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Mon, 15-Sep-86 08:37:18 EDT From: mckenzie@j.bbn.com (Alex McKenzie) To: mod.protocols.tcp-ip Subject: Ethernet Multiplexors
We have had various troubles attaching hosts to our BBN Ethernet using DELNIs. We haven't actually tried too hard to diagnose them all - simply noted that there are hosts which don't work when connected to a DELNI. We assume that DEC has probably "improved" or ignored some part of the host to transceiver protocol. We are now using large quantities of an Ethernet multiplexor made by TCL, Inc., 41829 Albrae St., Fremont, CA 94538 (415/657-3800). You buy a chassis with 9 card slots. You buy a "downstream" card and 1 to 8 "upstream" cards. Each upstream card can be either V1 or 802.3; I think this is also true of the downstream card but I'm not so sure. As I recall, a box with a downstream card costs about $400 and each upstream card costs about $100. We have had no troubles with these multiplexors, have successfully cascaded them, and I know of no hosts that can't use them. Regards, Alex McKenzie
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Sep 86 8:37:18 EDT From: Alex McKenzie <mckenzie@j.bbn.com> To: tcp-ip@sri-nic.arpa Subject: Ethernet Multiplexors
We have had various troubles attaching hosts to our BBN Ethernet using DELNIs. We haven't actually tried too hard to diagnose them all - simply noted that there are hosts which don't work when connected to a DELNI. We assume that DEC has probably "improved" or ignored some part of the host to transceiver protocol. We are now using large quantities of an Ethernet multiplexor made by TCL, Inc., 41829 Albrae St., Fremont, CA 94538 (415/657-3800). You buy a chassis with 9 card slots. You buy a "downstream" card and 1 to 8 "upstream" cards. Each upstream card can be either V1 or 802.3; I think this is also true of the downstream card but I'm not so sure. As I recall, a box with a downstream card costs about $400 and each upstream card costs about $100. We have had no troubles with these multiplexors, have successfully cascaded them, and I know of no hosts that can't use them. Regards, Alex McKenzie
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Mon, 15-Sep-86 10:05:48 EDT From: lyndon%ALBERTA%UQV-MTS%UMich-MTS.MAILNET@ncc.UUCP To: mod.protocols.tcp-ip Subject: (none)
From: lyndon@ncc.UUCP (Lyndon Nerenberg)
Newsgroups: net.video,mod.protocols.tcp-ip
Subject: Re: Ethernet between buildings
Message-ID: <722@ncc.UUCP>
Date: Sat, 13-Sep-86 19:32:57 MDT
References: <611.rbbb.titan@Rice>
Organization: Nexus Computing Corp., Edmonton, AB
Lines: 35
Summary: Not a wives tale!
I am cross-posting as this sort of relates to the discussion in
mod.protocols.tcp-ip about grounding ethernet cables...
In article <611.rbbb.titan@Rice>, rbbb@rice.edu (David Chase) writes:
> ... A sort of old wives tale of lightning protection says that you
> should put a tight loop in a wire near a good ground; the lightning sees
> that as a great big inductor, and hops over to the good ground.
>
> David
The "signal" introduced into a cable by a lightning strike consists of
extremely high frequency radiation. It does not take much inductance to
throw up a "brick wall" to it. Many television stations run their feeds
through a single loop at the base of the tower, then to the transmitter
shack. The RF from a lightning strike will (hopefully :-) take the easier
path from the feed line, through the base of the tower, to ground.
I handled the transmitter plant installation and setup for a local FM BCST
station a couple of years back. The antenna was located on top of a
building at the University. We were unable to properly ground the tower,
so we threw up a loop inside the roof house for the elevators ( *lots*
of metal in there :-)
I know a number of amateur radio op's in town who do the same thing - 2
turns of the feedline at the base (approx. 3 feet in diameter) before
entering the house. I can't say that any of them have been hit, so I won't
guarantee results. Then again, I have watched local TV broadcast towers take
direct hits without going off the air.
I'm sure a posting to net.ham-radio would provide some further information
on practical experiences of dealing with lightning hits.
--
Lyndon Nerenberg (VE6BBM) {ihnp4,ubc-vision}!alberta!ncc!lyndon
Systems Group - A Div. of Nexus Computing Corp. Envoy_100: Unix
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Mon, 15-Sep-86 17:19:27 EDT From: mckee@MITRE.ARPA To: mod.protocols.tcp-ip Subject: TCP/IP Conformance Testing
The following article was published in NETWORK WORLD, by Paul
Korzeniowski, 1 Sept. 86, pg 2.
Monterey, Calif. - Corporation for Open Systems (COS) supporters beware.
Ensuring that devices on a multivendor network really can work together
has proven to be a task too complex even for Uncle Sam.
Last week at the first Transmission Control Protocol/Internet
Protocol (TCP/IP) Vendor Workshop ("TCP/IP future at stake," Network
World, Aug. 25), the U.S. Defense Communications Agency announced it is
washing its hands of TCP/IP conformance testing.
The agency oversees transmission facilities that link government
agencies, universities, and corporations into one giant network of
networks. The umbrella network grew out of the Advanced Research
Projects Agency Network (Arpanet), designed in the late 1960s as the
world's first packet-switching net.
The original network has expanded so that today it supports more
than 30,000 computer systems ranging in size from Cray Research, Inc.'s
supercomputers to Apple Computer, Inc.'s Macintoshes.
For the last few years, DCA and a number of other government
agencies have been developing test suites and creating a center for
TCP/IP conformance. The work was similar to that undertaken by COS,
which will handle Open Systems Interconnect (OSI) conformance testing
and the development to test suites. At the workshop, two government
officials told attendees that plans for the center had been dropped.
The DCA has developed and continues to design conformance test
criteria, but they are not robust enough to ensure that all TCP/IP
products can interoperate. "There have been instances where vendors
have spent a lot of time and money trying to ensure their products would
perform on the government network," said Daniel Lynch, president of
Advanced Computing Environments in Cupertino, Calif. "When their
product was linked to another company's product, they couldn't
communicate."
Government officials declined to discuss the decision. But
conference attendees speculated the government found the task of
supplying comprehensive conformance tests nearly an impossible one.
One problem testers faced is that the only way to test a product
properly is to attach it to the target network, a procedure that the
DCA would not condone. Also, running a testing center requires a great
deal of money and engineering talent. Lynch said only a handful of
engineers are qualified to develop and run conformance tests.
The DCA decision leaves TCP/IP vendors with a number of unappealing
options. They could form a COS-like organization. But the consensus
seemed to be that fewer rather than more of such standards organizations
are needed.
Individual companies could develop their own testing procedures.
But the resources required for such self-testing could limit the number
of vendors able to bring TCP/IP products to market. Attendees formed a
task force to explore how vendors should proceed.
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Mon, 15-Sep-86 17:23:12 EDT From: cetron@UTAH-CS.ARPA (Edward J Cetron) To: mod.protocols.tcp-ip Subject: Ultrix 1.2 and unacceptable tcp packets
After hacking with the Tek tcp/ip package to add keep-alive (or probe-alive as the case may be) support, I found the following behaviour from two Ultrix sites: line sits idle for x length of time (so snd.nxt = snd.una = Ultrix rcv.nxt...) Tek tcp/ip sends a packet designed to be unacceptable in order to force a response (as documented in the mil-std and rfc for tcp). This packet has seg.seq = snd.nxt-1 and seg.ack = rcv.nxt-1 which is obviously unacceptable and should force and ack with the proper counters. The Ultrix site receives the packet, and promptly drops it off of the face of the earth (though apparently reading the code it does use it to update the window...) Am I missing something or is this indeed non-compliant? All of the 4.2bsd and 4.3 bsd sites handle this fine... I know what is different between the 4.3bsd and the Ultrix code but before I fix it myself, I want to be sure I haven't overlooked something and/or that other Ultrix sites have noticed this same problem.... thanx ed cetron%utah-cbd@utah-cs.arpa
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Mon, 15-Sep-86 18:49:31 EDT From: leong@ANDREW.CMU.EDU (John Leong) To: mod.protocols.tcp-ip Subject: Re: DELNI characteristics
On the subject of cascading DELNI, one has to be careful about one quirk. The Intel 82586 chip has, by default, a check that is not really in conformance of the Ethernet spec. It measures the time between transmit and receiving the signal back from the transceiver and signals whether the round trip time equates roughly to 50 meter of drop cable (nothing to do with the Ethernet slot time of 51.2 micro seconds or roughly 2.5Km). This test is quite bogus but some earlier version of DECNET software actually check for that return code and declares the world is sick accordingly. We have ran into that problem earlier on when we cascaded DELNI's since they introduced roughly 10 meter of cable worth of delay and we ran over the 50 meters.
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Tue, 16-Sep-86 05:36:52 EDT From: ROODE%BIONET@SUMEX-AIM.STANFORD.EDU (David Roode) To: mod.protocols.tcp-ip Subject: Re: DELNI characteristics
Reference on DELNI limitation to non-cascaded mode when connected to an Ether cable: EK-ETHV1-IN-002 Ethernet Installation Guide, Digital Equipment Corporation, 1984, Appendix E, p. E1: "If DELNI interconnects are cascaded, the top DELNI interconnect cannot connect to an Ethernet coaxial cable. A maximum of two layers of DELNI interconnects are permitted, with the second layer of DELNI interconnects operating in the global mode." -------
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Tue, 16-Sep-86 08:57:16 EDT From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) To: mod.protocols.tcp-ip Subject: DELNI characteristics
Date: Mon, 15 Sep 86 18:49:31 edt From: leong@andrew.cmu.edu (John Leong) ..... The Intel 82586 chip has, by default, a check that is not really in conformance of the Ethernet spec. It measures the time between transmit and receiving the signal back from the transceiver and signals whether the round trip time equates roughly to 50 meter of drop cable (nothing to do with the Ethernet slot time of 51.2 micro seconds or roughly 2.5Km). This test is quite bogus .... You can tell the chip to disable that feature. I think it's *on* at power-up. Gould used to use the round-trip-to-transceiver check; we asked them to disable it and I believe it's now off for all new Gould ethernet boards. Scott
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Tue, 16-Sep-86 10:56:00 EDT From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) To: mod.protocols.tcp-ip Subject: Re: Formatting Query
Tabs should be expanded at the source; not by any heuristic in some program that has no chance of guessing right. This is preferably the user's mail composition program, perhaps by a user profile switch, but it should not be done by the SMTP user side, or the SMTP sending side, or any other mail delivery program (SMTP isn't the only one that exists (surprise!!)). If the user's composition program doesn't have this feature, then the user should do the conversion if tabs are significant. You simply cannot send data from one place to the other unless you /know/ that both sides agree on how to interpret the characters. I believe the /only/ set of characters we all agree on are the 95 ascii characters space through tilde, plus NVT newline. I would have italicized /know/ but only other Lisp Machines would be able to see it without garbage characters...
-----------[000069][next][prev][last][first]----------------------------------------------------
Date: Tue, 16-Sep-86 11:34:00 EDT
From: Ata@RADC-MULTICS.ARPA ("John G. Ata")
To: mod.protocols.tcp-ip
Subject: Re: Formatting Query
Yes, you are correct...when I said SMTP mailer, I meant the mail
composition program that submits mail to the SMTP mailer. Sorry for the
confusion. I strongly believe that mail composition programs, should
for the most part, expand tabs to spaces unless overridden by another
command or control argument. This is because, in the vast majority of
cases, tabs are used to merely position the next character in a
particular column, so that tab expanding is then the right thing to do
given that there isn't a standard definition of tabstops over the
network. Of course, for those cases where tabs mean something else, the
user can override this, perhaps with a command/control argument. The
bottom line is that, in most cases, tabs will be vastly reduced in SMTP
message text.
As a matter of record, the standard Multics mail system does
not allow tabs at all whether local or network. Therefore, the mail
program will expand tabs BEFORE submitting to the SMTP mailer, just like
it will expand before submission into another local mailbox. Given that
tab characters are not allowed in messages, the server SMTP does also
expand tabs to maintain compatability with the rest of the mail system.
John G. Ata
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Tue, 16-Sep-86 12:18:40 EDT From: alexp@xios.XIOS.CA (Alex Pepple) To: mod.protocols.tcp-ip Subject: X.25 Board Inquiry
*** BUGS SPRAY ***
I'm looking for X.25 boards (Full X.25) for Multibus and VMEbus machines
to interface to tcp-ip and other protocols. Would anyone have a list of
companies offering QUALITY products of that nature?
Please reply directly to me. Sufficient Interest = Net Summary.
I'm waiting in anticipation for E-mail bits of your brainwaves! -:)
-- Alex
...The bitterness of POOR QUALITY is remembered long after the
sweetness of LOW PRICE is forgotten.
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Tue, 16-Sep-86 17:10:37 EDT From: louie@TRANTOR.UMD.EDU (Louis A. Mamakos) To: mod.protocols.tcp-ip Subject: Ultrix 1.2 and unacceptable tcp packets
I've noticed other TCP problems with Ultrix 1.2's TCP. After we installed ULTRIX on a MicroVAX system, we don't seem to be able to send mail to our Sperry 1100 system anymore. The connection just hangs after a bit. This concerned me greatly, being one of the authors of the TCP/IP software on the Sperry host. None of our other systems had any problems, (2.9BSD UNIX, 4.2 BSD UNIX, Wollongong VMS, FUZZBALL, *Ultrix 1.1*). Examination of trace data on the Sperry indicates that it's just waiting for more data on the SMTP connection after sending a window update. (Flame on) Our solution? Very simple. Trash Ultrix and run 4.3 BSD. Not only has DEC managed not to fix broken code, but they've even broken working code! I'll just bet DECNET works though. (Flame off) Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Fri, 19-Sep-86 09:32:26 EDT From: mrose@NRTC-GREMLIN.ARPA (Marshall Rose) To: mod.protocols.tcp-ip Subject: A new discussion group
I am pleased to announce the charter of a new discussion group.
ISODE@NRTC.NORTHROP.COM
ISODE is a discussion group which focuses on the ISO Development
Environment, an openly available implementation of some of the
higher-level protocols adopted by international organizations (ISO,
CCITT, ECMA). These implementations are hosted on top of TCP/IP
using the method discussed in RFC983. Appropriate topics are:
- questions about how to use ISODE (and announcements of ports to
other target environments)
- discussion of ISODE as a part of a TCP/IP to ISO migration strategy
- exchange of ideas regarding ISO-based applications running in
a native TCP/IP environment
- debate regarding where ISODE should go next
This list naturally has some overlap with the TCP-IP list, the ISO
list, and so on. Contributors are urged to use the appropriate list
based on their topic of discussion. If there is sufficient demand,
new sublists may be formed.
All requests to be added to or deleted from this list, along with
problems, questions and suggestions, should be sent to
ISODE-Request@NRTC.NORTHROP.COM.
Coordinator: Marshall T. Rose (MTR) <Bug-ISODE@NRTC.NORTHROP.COM>
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: Fri, 19-Sep-86 19:09:33 EDT From: braden@VENERA.ISI.EDU (Bob Braden) To: mod.protocols.tcp-ip Subject: Internet Multicasting for NETBIOS
I would like to comment on the use of Internet multicasting for the
implementation of NETBIOS over the DoD protocol suite.
Both of the proposed protocols for implementing NETBIOS quite properly
restrict the use of NETBIOS broadcast packets to the same local network.
This restriction is necessary because the Internet architecure has not
provided a reasonable Internet-wide broadcast/multicast mechanism.
However, I believe that this can be only a temporary restriction.
There is a clear need to extend the Internet architecture to provide a
multicasting mechanism, and in fact the NETBIOS application is an
excellent example of the requirement for "distributed binding" which
multicasting can provide.
There is active work on the development and experimental deployment of a
Internet multicasting facility, as described in RFC 966 and RFC988.
Since (as we proudly proclaim) our work is characterized by trying out
something new before writing a standards document, the multicasting
extension to the Internet architecture described in these RFC's is not
yet in the "proposed standard" stage, although we are moving in that
direction. Experimental implementations are now under development.
What are the implications for the NETBIOS protocol design effort?
**> Make sure your protocol is consistent with the proposed Internet
multicasting facility, so that the local-net-only restriction on
broadcasting can be removed from a NETBIOS implementation with
minimal work when and if Internet multicasting is generally
available.
At some point, the NETBIOS application could be a good demonstration of
the Internet multicasting facility. The vendors developing NETBIOS
implementations for the DoD protocol suite are concerned with making a
product and selling it, rather than in protocol development. However,
if NETBIOS is successful, perhaps customer interest in removing the
broadcast restriction will bring about a more active collaboration
between vendors and researchers interested in Internet multicasting.
Bob Braden
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Sat 20 Sep 86 15:16:34-PDT From: "Henry Dardy" <dardy@nrl-acoustics> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Cc: dardy Subject: RE: Ultrix 1.2 and unacceptable tcp packets
You are right: Decnet works perfectly! ***Cough, ghasp, wheeze***. Sorry, but your (flame on) hadn't cooled yet! Hank ------
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: Sun, 21-Sep-86 14:17:56 EDT From: tcs@USNA.ARPA (Terry Slattery) To: mod.protocols.tcp-ip Subject: Fiber Ethernet problem
We have a fiber optic based Ethernet product installed here and are
having a problem with a Gould 9050 being attached to the net.
DESCRIPTION:
We have the Codenoll ethernet on fiber optic product with the following
configuration:
----------- ~325M -------------- ~800M ---------------
|usna.arpa|-----------|Star Coupler|----------------|usna-gus.arpa|
----------- -------------- ---------------
|
| ~75M
|
---------------
|usna-cs1.arpa|
---------------
M = meters
Both usna.arpa and usna-cs1.arpa can communicate. Usna-gus.arpa can hear
some (most?) rwho packets from usna and cs1. Gus cannot send anything
out without error. A Gould 6050 which is co-located with usna can
communicate over the 325 meter segment without problems.
ANALYSIS:
Optical power measurements show -15db at usna and -12db at gus (better
polished connectors and lower loss cable are the difference). The
flux budget is 21db, so we are well within spec there.
A recent note to these lists leads me to believe that there is a timing
problem. Codenoll supplied the following timing info:
Device Delay (ns)
Controller encoder 100
Xcvr xmit 300
Fiber cable (1600 meters@4.33ns/m) 6928
Xcvr rcv 650
Xcvr cable (60 meters@5.13ns/m) 308
-----
TOTAL 8386
I have connected the Gould and a Tektronix 6130 to a TCL MP station
and they communicate without problems, thus proving that the interface
is working correctly.
MISC. INFO:
The Gould Ethernet Controller Model 8561 Tech. Manual (May 85)
says that it tries 16 retransmits before giving up completely.
It also mentions a control bit described as:
"Transmit even if no arrrier sense signal is detected."
The driver doesn't include any code to modify this bit; it
is automatically reset upon board power-up.
QUESTIONS:
Is the timing out of spec with respect to what the Gould ethernet
interface is capable of handling?
What time delay does most equipment expect?
Does anyone else have experience with this or Siecor's product over
the distances involved here?
Are there more details available on what Gould did w.r.t. the problem
reported at Perdue?
Please respond directly and I will summarize the responses. Thanks,
-tcs
Terry Slattery U.S. Naval Academy 301-267-4413
ARPA: tcs@usna.arpa
UUCP: decvax!brl-smoke!usna!tcs
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: Sun, 21 Sep 86 14:17:56 EDT From: Terry Slattery <tcs@USNA.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: gouldbugs@BRL.ARPA Subject: Fiber Ethernet problem
We have a fiber optic based Ethernet product installed here and are
having a problem with a Gould 9050 being attached to the net.
DESCRIPTION:
We have the Codenoll ethernet on fiber optic product with the following
configuration:
----------- ~325M -------------- ~800M ---------------
|usna.arpa|-----------|Star Coupler|----------------|usna-gus.arpa|
----------- -------------- ---------------
|
| ~75M
|
---------------
|usna-cs1.arpa|
---------------
M = meters
Both usna.arpa and usna-cs1.arpa can communicate. Usna-gus.arpa can hear
some (most?) rwho packets from usna and cs1. Gus cannot send anything
out without error. A Gould 6050 which is co-located with usna can
communicate over the 325 meter segment without problems.
ANALYSIS:
Optical power measurements show -15db at usna and -12db at gus (better
polished connectors and lower loss cable are the difference). The
flux budget is 21db, so we are well within spec there.
A recent note to these lists leads me to believe that there is a timing
problem. Codenoll supplied the following timing info:
Device Delay (ns)
Controller encoder 100
Xcvr xmit 300
Fiber cable (1600 meters@4.33ns/m) 6928
Xcvr rcv 650
Xcvr cable (60 meters@5.13ns/m) 308
-----
TOTAL 8386
I have connected the Gould and a Tektronix 6130 to a TCL MP station
and they communicate without problems, thus proving that the interface
is working correctly.
MISC. INFO:
The Gould Ethernet Controller Model 8561 Tech. Manual (May 85)
says that it tries 16 retransmits before giving up completely.
It also mentions a control bit described as:
"Transmit even if no arrrier sense signal is detected."
The driver doesn't include any code to modify this bit; it
is automatically reset upon board power-up.
QUESTIONS:
Is the timing out of spec with respect to what the Gould ethernet
interface is capable of handling?
What time delay does most equipment expect?
Does anyone else have experience with this or Siecor's product over
the distances involved here?
Are there more details available on what Gould did w.r.t. the problem
reported at Perdue?
Please respond directly and I will summarize the responses. Thanks,
-tcs
Terry Slattery U.S. Naval Academy 301-267-4413
ARPA: tcs@usna.arpa
UUCP: decvax!brl-smoke!usna!tcs
-----------[000077][next][prev][last][first]----------------------------------------------------
Date: Sun, 21-Sep-86 14:50:03 EDT
From: dardy@NRL-ACOUSTICS.ARPA ("Henry Dardy")
To: mod.protocols.tcp-ip
Subject: RE: Ultrix 1.2 and unacceptable tcp packetsYou are right: Decnet works perfectly! ***Cough, ghasp, wheeze***. Sorry, but your (flame on) hadn't cooled yet! Hank ------
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 22 Sep 86 11:19:00 PST From: <gary@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic> Subject: Standard X.25 on Arpanet
Hans, I would be extremely interested in what you find out. As it would be germane for this group, could you please publish your findings? Thanks, Gary . ------
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: Mon, 22-Sep-86 10:43:47 EDT From: hwb@MCR.UMICH.EDU (Hans-Werner Braun) To: mod.protocols.tcp-ip Subject: Standard X.25 on the Arpanet.
Hi: I am wondering about who is using Standard X.25 to connect to an Arpa IMP (PSN) these days. Not HDH, not DH or LH (no 1822 at all), no Basic X.25 and not on the Milnet. Just plain Arpanet Standard X.25 attachments. I would appreciate a note if you are connected like that and would also be interested in what machine/operating_system/interface you use and eventually whether you saw any problems with such a setup. -- Hans-Werner
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: Mon, 22-Sep-86 12:00:51 EDT From: mckee@MITRE.ARPA To: mod.protocols.tcp-ip Subject: Comm. Fault Recognition/Diagnosis
For those of you interested in communications network fault recognition and diagnosis, the 15 Sept. issue of Datamation has a survey article by Bill Musgrave; "Sorting Out The Solutions", page 98. H. Craig McKee
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: Mon, 22-Sep-86 15:19:00 EDT From: gary@acc.arpa To: mod.protocols.tcp-ip Subject: Standard X.25 on Arpanet
Hans, I would be extremely interested in what you find out. As it would be germane for this group, could you please publish your findings? Thanks, Gary . ------
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: Mon, 22-Sep-86 22:06:51 EDT From: rms@ACC-SB-UNIX.ARPA (Ron Stoughton) To: mod.protocols.tcp-ip Subject: X.25 on Arpanet
Hosts requiring X.25 Standard service must be connected to an IMP running PSN6. I am not certain, but I don't believe many (if any at all) Arpanet IMPs have been converted to run PSN6. Many will require a hardware upgrade (C/30 to C/30E). Maybe someone from BBN can comment on this and give a schedule for upgrading the Arpanet IMPs. Ron Stoughton rms@acc-sb-unix.arpa
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 1986 05:53-PDT From: STJOHNS@SRI-NIC.ARPA To: rms@ACC-SB-UNIX.ARPA Cc: tcp-ip@SRI-NIC.ARPA, gary@BRL-SAGE.ARPA Subject: Re: X.25 on Arpanet
As of this writing and speaking semi-authoritatively I believe that all of the PSNs on the ARPANET have been upgraded to C30E. I am not sure of the status of the PSN software though on that side of the net, but the plan was to field PSN 6 as quickly as possible. Mike StJohns (DDN PMO)
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: Tue, 23-Sep-86 10:15:08 EDT From: jseeger@CC5.BBN.COM To: mod.protocols.tcp-ip Subject: Re: X.25 on Arpanet
All, ARPANET nodes have been upgraded hardware-wise to C/30e's. The upgrade to PSN 6.0 software is proceeding now. However, all nodes have been running PSN 5.0 for several months, and x.25 standard service was even possible before that, under PSN 3.0/4.0 (although it required the loading of a separate x.25 package). -Josh Seeger (BBN Communications, Network Analysis)
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: Tue, 23-Sep-86 12:50:17 EDT From: fserr@CC5.BBN.COM (Frederick E Serr BBN 3/176 x2474) To: mod.protocols.tcp-ip Subject: re: X.25 on ARPANET
The hardware upgrade on the ARPANET is complete. PSN 6 has been deployed to a few nodes, and deployment to other nodes in ongoing. I am not certain if a definite schedule has been established for the remaining nodes, but I would expect that all ARPANET nodes would be running PSN 6 within one month. Fred Serr BBNCC Network Analysis
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 23 Sep 86 12:50:17 EDT (Tue) From: Frederick E Serr BBN 3/176 x2474 <fserr@cc5.bbn.com> To: hwb@mcr.umich.edu Cc: tcp-ip@sri-nic.ARPA Subject: re: X.25 on ARPANET
The hardware upgrade on the ARPANET is complete. PSN 6 has been deployed to a few nodes, and deployment to other nodes in ongoing. I am not certain if a definite schedule has been established for the remaining nodes, but I would expect that all ARPANET nodes would be running PSN 6 within one month. Fred Serr BBNCC Network Analysis
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: Wed, 24-Sep-86 18:07:01 EDT From: tcs@USNA.ARPA (Terry Slattery) To: mod.protocols.tcp-ip Subject: Fiber Ethernet problem solved
The fiber ethernet problem has been solved. This is rather long (~200
lines) and includes info supplied by various people on the net. If you
only are interested in the solution, skip down to "THE SOLUTION".
First, a synopsis of the problem.
SYNOPSIS
A Gould 9050 connected via a Codenoll Ethernet over fiber optic network
wouldn't talk to a Vax 780 (or Gould 6050 co-located with the 780). The
Goulds run thier UTX Unix product. The fiber's optical power levels
checked out to be within spec. The 9050 could hear rwho packets from
the 780. The 9050 would report errors on EVERY outgoing packet. Timing
estimates showed the 9050 getting receive carrier about 8us after
transmit started. The controller manual noted a bit which when set
would:
"Transmit even if no arrrier sense signal is detected."
but the driver didn't contain code to set the bit. A recent note to
these lists from Cornell (I hope this is right this time) suggested that
the 9050 needed to have this bit set.
INPUT FROM OTHERS ON THESE LISTS
From: swb@devvax.tn.cornell.edu (Scott Brim)
I'm pretty sure I know what that bit is (haven't looked at the Gould
ethernet manual for a year) -- and I don't think it's your problem --
but here's an explanation of the bit: The Gould board uses the 82586
controller chip. There's an option in the 82586 to look for its own
signal coming back from the transceiver within a certain amount of
time. It used to be that you couldn't use a "transceiver cable" more
than a certain length (I remember 6 ns, but that seems awfully short).
They turned this off for us -- it's just a change to an initialization
bit in the PROMs on the Ethernet board.
Scott
[Ed note: I didn't get any info from Gould on the actual time delay over
which the system would break, but our 6050 would work in place of the
780 and the time delay there was ~4us (calculated and measured).]
From: <BEAME%MCMASTER.BITNET@WISCVM.WISC.EDU>
Here at McMaster University we have a star coupler with 4 legs of
around 1500 ft. . We were using Codelink 2020A modems, we found that
we were able to transmit from leg 1 to leg (2,3,4) and leg 2 to leg (1,3,4)
we were unable to transmit from leg 3 to leg 4. This problem cleared up
after trying several modems on leg 4. Thus the matching of modems IS
important.
Next, if you are using 2020A's, the echo from the modem (back down the
receive line while transmitting) is not done within the modem but at
the star coupler. Thus a machine might complain about late echo.
We have just installed some 3030A's which do local echo and block out
the echo from the coupler and all of our problems an