@DCN6.ARPA:mills@dcn6.arpa (10/14/85)
From: mills@dcn6.arpa Folks, Over the weekend I cobbled up a driver to connect my LSI-11/73 fuzzball to the Heath HD-4040 TAPR board running the WA8DED firmware in host mode. The driver provides interactive access from the operator terminal to the TAPR board as well as Internet datagram access to our local net and the Internet world. My intent was to bring up an experimental (access controlled) IP datagram gateway in the Washington, DC, area. I found good news and bad. The good news is that IP datagrams fly quite handily in connection mode. I was able to connect to myself (via the WB4JFI-5 digipeater) and read the mail on my fuzzball via the radio channel, which provoked some solid citizens to ask what I was doing with all those unprintable characters. (Turns out one of the solids was a coordinator for the DDN IP/TCP implementation program!) The flow control and opaque coding problems I had with the orginal TAPR firmware are absent. I was able to change the protocol-id field from the default (F0) to the value assigned for IP (CC), but I doubt this avoided the clutter on the screens of the curious eavesdroppers. I conclude the lashup works in connection-oriented mode. The bad news is that the drat thing does not play in connectionless mode. The WA8DED firmware apparently refuses to believe the user is interested in U frames as data and presents them as monitoring information instead. I can understand the implementor's reluctance to horse around in this area, since to do it right requires that the level-2 source route and protocol id be available to the host. The WA8DED code attempts to hide all level-2 details, which makes this hard. I would rather the entire packet, along with source route and protocol id, be passed on to the host, instead of just the data field. As most of you probably know, the WA8DED firmware implements four virtual channels, although they cannot be separately addressed from the radio side. Thus, it should be possible for up to four remote TAPR/IP hosts to connect to an Internet host on the other side of my fuzzball gateway, each on a separate channel. This requires some way to associate return datagrams with the right channel, which will require some sort of dynamic IP-address-to-callsign mapping table. We Internetters have faced that problem before - with Ethernets and X.121 public nets, not to mention volleyball tournaments. It may be possible to fool mother nature by peeking at the first octet of the monitoring message and capturing source routes in a configuration table, possibly dynamically updated using the monitor-message header, which is available in formatted form, but such heroics must await another weekend. Meanwhile, if I can flush another LSI-11 rabbit from the underbrush here, the first IP/TCP two-way may yet come to pass. Dave, W3HCF -------
fair@ucbarpa.BERKELEY.EDU (Erik E. &) (10/15/85)
I may have missed the point, but why bother running IP over X.25, when IP (as a pure datagram protocol) is ideally suited to packet-radio? Of course, I'm somewhat flush with missionary spirit right now, since I just finished Michael Padlipsky's book, ``The Elements of Networking Style'' (Prentice-Hall, 1985) It seems to me that if you're the only one doing IP right now, you can build a superior network up from scratch, which might (if you made it easy for them) convince the rest of the packet-radio community to convert by example. I think that it would be terrific to have a public, ARPANET-style resource-sharing network running over packet-radio, instead of an X.25 based terminal-to-computer network which that protocol implies. Also, by running IP over X.25, you're stuck with the limitations of the X.25 protocol (e.g. no alternate routing) unless you're doing something clever that I didn't spot in your description. On the other hand, since this list is based partially on the ARPANET, maybe I'm preaching to the converted... Erik E. Fair ucbvax!fair fair@ucbarpa.BERKELEY.EDU
karn@petrus.UUCP (Phil R. Karn) (10/15/85)
> I may have missed the point, but why bother running IP over X.25, when > IP (as a pure datagram protocol) is ideally suited to packet-radio? I couldn't agree with you more! The problem is that "AX.25" is a very poor term to describe the protocol run by the amateur packet radio community. What we call "AX.25" is really just LAPB (the link layer of X.25) with a prepended datagram header consisting of amateur callsigns (with optional source routing through a bunch of digital repeaters, or "digipeaters".) It does NOT have the Packet Layer from X.25 (as of yet, anyway...and I am determined to do everything in my power to prevent that from happening.) It is possible to use "AX.25" in "datagram mode", i.e., by bypassing the connection-oriented LAPB layer and sending raw packets prepended by the link-level amateur callsigns. However, amateur packet radio is one of those few places where link level acknowledgments make sense, because the links are so unreliable that the chances of a packet making it successfully down a long chain of them approaches zero asymptotically. My view of a real amateur packet network involves IP gateways speaking to their neighbors over AX.25 point-to-point links. If they have excellent quality RF links, with few collisions, they default to AX.25 unconnected mode; otherwise they use the link level connect facilities of AX.25 to increase the chances of each datagram making it to the next node. The users, of course, speak TCP, and this may be the biggest challenge of all... Phil
brian@SDCSVAX.ARPA (10/17/85)
From: brian@SDCSVAX.ARPA (Brian Kantor) Actually, the reason for x.25 under tcp/ip is a practical one only - the equipment is there already. Think of them as error-free radio modems. By using existing packet radio boxes to implement the point-to-point links in a packet network, we get error-free links between the nodes in the network. If data traversing the network is sent as IP datagrams over such a network, it can be rerouted in true datagram style at each network node, thus giving the flexibility of a datagram based service with the high reliability of connected nodes. Certainly some other transport mechanism could be used between network nodes. AX.25 boxes exist and will simplify getting a network built. Although they have disadvantages (such as really short maximum packet sizes), their existance and useability means that we only have to build the network, not also design a new transport mechanism for it. Undoubtably you are aware, Erik, that the Internet Protocol packets are almost never sent in raw form. They are usually encapsulated in an underlying transport protocol such as ethernet, slip, 1822, etc. No, its not exactly ISO 7-layer standard. But this is the real world. And it works well. There are some philosophical arguments (perhaps they are practical arguements also) as to whether the IP datagram should be generated in the user's equipment, or in the network connection node. You can compare this to whether your terminal at home is using a modem (and thus 212 or 103 protocol) to connect to your vax at work, which generates the IP stuff for you, to the idea of having a standalone system at home that actually makes IP packets and sends them to your vax which gateways them onto the network (as with a Sun running SLIP, for example). Both will work just fine. The second requires more processor power in the user's equipment, but provides a much more flexible facility. What we are trying to do in building the ham packet radio network (AMPRNET) is to provide the most flexible, most useable, and least restrictive network we can within a framework of almost no money and complete anarchy. The idea is to accomodate both the dude who just bought a packet box for local communication, and now wants to use the network, and also the guru who has a lot of computing power and builds an IP box. The guru is clearly going to get more out of the network than the appliance operator, but both can use the network. Gad I've typed a lot before 7 am.... Brian Kantor WB6CYT UC San Diego Network Services Group decvax\ brian@ucsd.arpa ihnp4 >--- sdcsvax --- brian ucbvax/ Kantor@Nosc