Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site timeinc.UUCP Path: utzoo!decvax!decwrl!greipa!pesnta!phri!timeinc!dwight From: dwight@timeinc.UUCP (Dwight Ernest) Newsgroups: net.ham-radio.packet Subject: Networking Notes from N5EG (TEXNET) (3 of 4) Message-ID: <371@timeinc.UUCP> Date: Wed, 31-Jul-85 15:57:58 EDT Article-I.D.: timeinc.371 Posted: Wed Jul 31 15:57:58 1985 Date-Received: Sat, 3-Aug-85 02:41:39 EDT Reply-To: dwight@timeinc.UUCP (Dwight Ernest) Distribution: na Organization: Time, Inc. - New York Lines: 192 [ Note: This series of articles was found on Compuserve and downloaded from HAMNET there on 21 July 1985 by Dwight Ernest KA2CNN 70210,523. ] An Introduction to Networks part 3 by T.C. McDermott, N5EG networks SIG, TPRS The last article discussed End-to-end Vs. Hop-to-hop methods of acknowledge, and the attendant advantages of each. As you may recall, one of the disadvantages of the HHA was the possibility of a network failure still allowing the sender to have been acked for data that may not, in fact, have been received. Generally, this is not a problem. If communications fails along a path we naturally tend to want a re-transmission of the entire contents of whatever file we may have been sending. If we happened to be in the keyboard mode, then since the communications fialed, we cannot continue to send anyway. Thridly, our TNC's do not tell us how much data they have in their transmit buffers that has not been acknowledged, so the HHA network really doesn't differ from the types of responses that we are used to from the TNC - LAN system. If we must guarantee the absolute integrity of a file transfer, then we should implement some type of block numbering and sequencing program that controls the file transfer process. In essence, something like the MODEM7 protocol tacked on top of our existing TNC protocol would guarantee the complete integrity of files transfered. We would probably want to add onto the MODEM7 system a little bit, perhaps to record what was and was not sucessfully transfered, and perhaps a method of automatically re-establishing the connection to the other station, and continuing with the transfer process until it is sucessfully completed, and then tearing down the connection. This additional program that we would run on each of our end-user computers (both sender and receiver) is the LAYER 4 of the OSI model - the transport layer. Since the network we are talking about constructing is thus releived of absolute ACK integrity by the presence of this additional program (in those rare instances where it is really needed) then our netork is only restricted to providing a reasonable guarantee of integrity, perhaps guaranteeing that packets arrive in the correct sequence, and without bit errors. Thus with an emphasis on the HHA VS. the EEA methods, we have decided to build a network that optimizes throughput and response, allowing for a layer 4 program in the event it is needed, but not sacrificing the performance of the network for the vast majority of the uses of the network. This trade-off is usually described as a speed-integrity tradeoff in the literature. Now that a decision has been reached on the desired attributes of the network, that is speed, and simplicity, we may concentrate on one final interface aspect, and that is how the LAN (i.e. the TAPR TNC's) are to interface and establish connection through the network. This linkage is the peer communication between two layer 3 processes that is described by Tannenbaum [1]. In the 7-layer OSI model, subnet communication (that is communication through a network) is established between two layer 3 processes - that is, the TAPR TNC AX.25 mode, and the network entrance and exit layers. Although AX.25 is sometimes discussed as a layer 2 protocol, in the LAN application it is really a layer 3 process. It establishes, communicates, and terminates, and thus it is a layer 3 process. Similarly the network, upon command, will establish, communicate, and terminate, thus it also is performing a layer 3 function. Why the concern about which layers to call each other? Because it is desirable that the TNC's be able to use the network without any modification. Thus the network must be compatible to the way that the TNC establishes, maintains, and terminates connections, since the network must establish, maintain, and terminate connections to or from TNC's and itself. We are faced with the choices as to how the TNC and the network can talk with one another. One method of network interface is to assume that the network is transparent, that is it looks like a digipeater. Then you would use your TNC as though the network were a single digipeater (even though it might have many hops, it would appear to the TNC as one digipeater). Another method is to treat the network as a spearate LAN address. This is, you would connect to the network. Then the network would engage in an interactive session with you regarding the type of service that you needed, that is, who you wanted to talk to, and how to get through the network to that place. Once the network computer was satisfied, it would then engage in comunications between the endpoints. Your TNC would think it was connected to the network, not to your actual destination station. Each of these connection methods has advantages and disadvantages. We will discuss some of them here. The digipeater-emulation method is a very natural method to use, because the connection method is familiar to all of the TNC users. Let us establish the following scenario: WD0ETZ in Carrollton wishes to communicate with WD5GAZ in Houston. WD0ETZ knows that this distance will require the use of the network. So WD0ETZ proceeds as follows... Connect WD5GAZ VIA DALLAS This seems simple enough, but some interesting problems crop up almost immediately. How does the network know where to find WD5GAZ? What path is required to get there? WD0ETZ's TNC is going to want to see ACK's from WD5GAZ, not from DALLAS. First problems first. One way for the network to know how to find WD5GAZ is for it to keep tables in all of the sites of each and every network user. This is really not practical in an amateur environment because hams move, come, and go, and even change callsigns, and with very many users, it takes a lot of manual intervention to keep the tables current. It also takes a lot of computer power in the network to store and route messages based upon these tables. In the event of a network crash, the tables would have to be reloaded, etc. A simpler way would be for the originator, in this case WD0ETZ, to specify the network "hop-off" point, that is, the location in the network where WD5GAZ is likely to be found. For example: Connect WD5GAZ VIA DALLAS,HOUSTON Now the network knows that the entry point is this network (which is "DALLAS", the one hearing WD0ETZ) and the exit point is HOUSTON. Perhaps different types of names would be chosen for network nodes. Grid-squares and major city names seem to be two obvious choices. What about the route to take to get along the network? There is an incomplete but simple answer to this question - make a linear network (or a simple variant of linear). A linear network is one where the network is basically a straight line. Thus there is by definition only one path between any two points. A few other questions. What if WD5GAZ is not within range of the HOUSTON node, but perhaps within range of a station that is near to the node - for example suppose that WA5AAA is between the HOUSTON node and WD5GAZ. Then... Connect WD5GAZ VIA DALLAS,HOUSTON,WA5AAA What if WD0ETZ is not within range of the DALLAS node, but is within range of WB5QNG, who is within range of DALLAS ? Connect WD5GAZ VIA WB5QNG,DALLAS,HOUSTON,WA5AAA Well, the addressing would work. But the network entry point has to do some strange things to the address field. Remember in the HHA scheme it would be the address DALLAS that is actually ACKing WD0ETZ, and not WD5GAZ that would be ACKing WD0ETZ, so the network node has to play "fast-and-loose" with the address headers in the digipeat field. The other method is fairly straight forward. The user connects to the network, and then enters an interactive Q & A session: Connect DALLAS Welcome to TEXNET - DALLAS node. There are currently 4 other users connected to DALLAS. Enter destination callsign ? ( WD5GAZ would be entered here) Enter network exit node ? ( HOUSTON would be entered) Enter destination digipeaters ? (WA5AAA would be entered) CONNECTION ESTABLISHED - PROCEED Notice one thing in the above scenario: more than one station may be connected to the network node entry and exit points. This is something that is a little foreign to the AX.25 protocol, that is MULTIPLE VIRTUAL CHANNELS to a single TNC. In this case it is still compatible with AX.25 since both source and destinations callsigns are part of the AX.25 standard. Only the network nodes have to have this special property of having to be connected to several different stations simultaneously - thus the AX.25 code for these controllers is a little different from a normal implementation. But only the network requires these special TNC's (actually they are built into the node controller, and aren't identifable as a separate device). The reason that the network should allow for multiple virtual channels is to allow multiple people to simultaneously use the network. Since we will put high-speed radios in the network between nodes, we should take advantage of the bandwidth available. At this point we will not go into the network protocol required to implement these connection schemes, that "play-games" with the address header fields to keep our TNC's happy, and that perform the HHA transfer between the network nodes, do flow control inside the network, and route the signal to the destination. That is the subject of another article. The next article will deal with the type of hardware that will be required to support this concept of a network, and it turns out to be surprisingly modest. There are some other concerns about capacity, response time, channel utilization, reliability, and remote network "resuscitation" (in the event of software failure) that will also be addressed in part 4 of this series. -- ----------------------------------------------------------------------------- --Dwight Ernest KA2CNN \ Usenet:...vax135!timeinc!dwight Time Inc. Edit./Prod. Tech. Grp., New York City Voice: (212) 554-5061 \ Compuserve: 70210,523 Telemail: DERNEST/TIMECOMDIV/TIMEINC \ MCI: DERNEST "The opinions expressed above are those of the writer and do not necessarily reflect the opinions of Time Incorporated." -----------------------------------------------------------------------------