====== "GlobalNet" - A Global Packet Routing System ====== By Paula G8PZT\\ Spring 2004\\ Reproduced from UK Amateur Packet Radio Conference 2004 Proceedings\\ ===== 2023 Foreword ===== While it is reportedly still present in xrouter, GlobalNet ultimately did not take off. However, the underlying thinking is still of interest and so this document is preserved here. ===== Abstract ===== This presentation is about a possible global networking scheme for Packet Radio. I will try not to get too deep, but deep enough to give you a taster of what It’s all about. ===== Introduction ===== A few years ago, whilst sitting on a beach watching people "texting" on their mobile phones, it occurred to me that here was a relatively slow wireless message delivery system, which for all its limitations had become a so-called Killer Application. So why couldn’t we do something similar with Packet radio? Could text messaging become the Killer App to keep Packet alive? After all, we now had rigs with built-in TNC’s, and we had a network which had been moving text around for 15 years or so. All we needed was software and protocols. I had played with APRS messaging, but it was quite unimpressive. It relied too heavily on part-time digipeaters on a single congested frequency, and it had a limited "horizon" of 2 or 3 hops. What we needed was something which could deliver messages reliably over long distances. Something which used the existing network. Nearly 20 years in the Packet game has taught me that it’s no good just talking about new ideas, because nothing will ever get finalised. The only way to get new things accepted is to do them, and show that they work. So I set to work on a scrap of paper there in the sun, and have been quietly beavering away at it ever since. There were several things to work out, but underlying them all was the need to route packets from a source node to destination node anywhere in the world without any knowledge of the intervening networks. Until that could be done, the rest was academic. ===== GlobalNet Project Overview ===== The main focus of my work over the last few years has been to develop the infrastructure software and protocols with which to build a global packet radio network. The primary goal of such a network was to support packet text messaging, but also to allow any station to connect to any other station without need to know the routing. It will provide new services, and be extensible to support future transport protocols. Hopefully this will encourage and facilitate the development of new applications, as yet undreamed of. We already have a global network - it’s called the Internet. But whilst I am happy to use the Internet where necessary as part of the infrastructure, I firmly believe we should use radio where possible, and of course the "local loop" between the end user and the network access point will be radio. That’s the whole point of packet radio. If we simply connected all the access points points to the Internet, and used TCP/IP over the local loop, we’d have our global network, but it would be totally dependent on the Internet, and we’d simply be consumers of other people’s software and protocols. Where’s the challenge in that? Let’s be different; let’s develop our own protocols; experiment, make mistakes, try again. In short, be radio hams! ===== Limitations of Existing Network ===== Let’s examine some of the limitations of the existing Packet network, so we can see what we’d like from a new network. Imagine you’re on holiday in Spain, and you have a portable packet station. There’s a local node so you’d like to connect back home to Birmingham and tell your mate what a nice time you’re having. Or you’d like to check if you’ve got any packet mail. Trouble is, the Birmingham node isn’t in the nodes table, it’s full of EA callsigns instead! If you’d done your planning before you left home, by mapping the network, you would probably be able to node-hop your way back to Birmingham. But if you had no prior knowledge of the network, you could spend a very long time trying to find suitable stepping stones. Another problem is that each stepping stone has an inactivity timeout, so if the round trip time gets long and you don’t keep the data flowing, the link will drop. (This can also be a darned nuisance if you’re working a chat server via a node hop). Ordinary users aren’t part of the network; you can’t connect directly to them. You have to connect to their local node and connect out on the correct port, assuming you *know* which one they are on at the time. Finally, NetRom has no formal "datagram" mode. You can’t send a single self contained packet from one end user to another, and this stifles the development of new applications. ===== The Requirements ===== So now we know what’s wrong, let’s look at what would be desirable: Firstly, we need a global addressing and routing scheme which would allow any station to contact any other station in effect "directly", without any intermediate connections and without having to know the routing. For example switch on your packet system, type "CONNECT ZL2VAL" and get connected. The routing system must be able to support any layer 4 transport protocol, and must include a datagram mode, so we can send single packets. It should include a control message protocol, to allow the software to make decisions and help us diagnose problems. Finally, any new system must remain compatible with existing hardware, software and protocols. We can’t simply sweep everything away and start again. There will always be those who can’t or won’t change, and other people will have their own ideas of how it should be done. We can achieve change in an evolutionary manner, little by little. If the changes are good, they will be widely adopted, if not they simply die and the system carries on as before. ===== Existing Routing Protocols ===== Can we realistically achieve our aims using any of the existing protocols? NetRom is very widely used, works well on radio, is easy to understand, and the routing is fairly self-configuring. But with only a finite space for the nodes table, it has a limited horizon. It’s not scalable, for instance it couldn’t cope with a nodes table of 100,000 nodes. It also has no datagram mode, and doesn’t lend itself to direct user to user circuits. IP on the other hand is globally routable, it allows direct peer to peer circuits, and it supports a datagram protocol. But it was designed for wired networks, so it needs near-perfect radio links. The protocol is also verbose, which makes it inefficient on radio. It’s not easy to understand, and in the amateur world has suffered from unreliable and difficult software. Despite my attempts to get an IP router into every node, there isn’t a realistic possibility of getting everyone to run IP. I don’t know much about ROSE, other than the fact that it uses addresses which are like telephone numbers. The protocol seems to be secret, but it would appear to have the potential for global routing. However, there’s no chance of getting a significant number of sysops to run it. Flexnet is another secret protocol, but would seem to have similar horizon problems to NetRom, unless the sender specifies the route, which is not acceptable. Once again, if it was going to catch on, it would have done so already. In my view, secret protocols, however good, are a non-starter, because they don’t facilitate expansion, and they don’t allow alternative software to be used. It is unrealistic to expect everyone in the world to use the same software. ===== How To Achieve Our Aims? ===== Ok, so up to now I seem to have been very negative. Given that we will never get the whole network to use the same software, yet the existing protocols are not suitable, how on earth do we achieve our aims? The answer I feel is to compromise. In an ideal world we could sweep the whole lot away and start again, but that is not possible. What we *can* do is use the existing netrom network, by making an extension to NetRom itself. We can then build a new network without breaking the existing one. Some of the nodes in the NetRom network would also be GlobalNet routers. These nodes would form a network of their own, exchanging GlobalNet traffic through the NetRom network. They could also tunnel GlobalNet through TCP/IP networks. By making the protocol open and extensible we allow any software author to implement it, experiment with it, and develop it further, thus ensuring maximum penetration. I want this to be a virtual private network One of the nice things about Packet Rado is that it’s free from all the spamming and jamming and hacking that goes on in the Internet world. Bear that in mind if you think we don’t need our own protocols. ===== Global Routing Principles ===== As mentioned before, NetRom is not scalable. This is because it is a single boundless network, and even if you had enough memory for a 100,000 node table, it would be impossible to exchange the volume of routing information fast enough to keep the network stable. IP doesn’t have this problem, because it doesn’t have nodes tables, and the network is composed of self-administrating subnets, so there is never a need to move routing information around the whole network. The key to this is the address format. NetRom addresses are simply callsigns, which don’t give much clue where the station is located or how to reach it. GB7PZT is in England, but where? IP addresses are organised into a hierarchy, either geographically or topologically, and can be used for routing. For instance the address 44.131.91.2 is globally routable. The 44 indicates the ham radio network, 131 indicates the UK, 91 indicates north Worcestershire, and the 2 is assigned to GB7PZT. The whole of the amateur IP network can be hidden behind a single gateway, and all the non-amateur networks need to do is route any address beginning with 44 to that gateway. The gateway knows how to reach the major routers in each country, and they in turn know how to reach the regions and so on. This is called implicit routing. The packet tells the routers where it should go. GlobalNet needs to use implicit routing. ===== Address Format Requirements ===== We need an address format which uniquely identifies a particular station in the world, bearing in mind that one person may have several stations. It should also tell us how to reach that station. It needs to be easy to allocate. We don’t want people to have to wait for an overworked world coordinator to hand out the addresses. If co-ordination is required, it should be done at local level. Addresses need to be easy to remember. We are fairly good at remembering callsigns, words and certain telephone numbers, but not good at remembering random character strings or serial numbers. The key to this is that the address must have *meaning*. This helps us to mentally cross reference the address with other concepts, and reconstruct it when it gets hazy. Contrast these two telephone numbers - the first one is organised as city, exchange, user, and we tend to remember the individual sections by linking them to other concepts in our brain. The mobile number has no meaning, and we find it difficult to remember. Lastly, since there are two addresses in every packet, they should be as compact as possible, to avoid wasting too much space. ===== Address Format Possibilities ===== If we want to allow people to assign their own addresses without central coordination, they must include some unique component, such as a callsign. Callsigns with SSID’s allow one person to have up to 16 stations, but aren’t implicitly routable. We could add a geographic component such as a QRA locator, allowing packets to be routed sufficiently close for the callsign to be used. But the network topology isn’t strictly tied to the geography. For example, you might assume South Africa should be routed southwards from the UK, when in fact the best route might be via Iceland. Alternatively, since networks tend to be organised on a country-by country basis, we could use country and region codes with callsign and SSID. The assumption would be that once the packet reaches the country it can be routed on region, then on callsign. Whilst the numbers don’t take up much space when coded, the callsign, which forms the bulk of the address, imparts no useful routing information, so it would be better to replace it with numbers. Unfortunately this requires coordination to assign the serial numbers. As with telephone numbers, the country code could be omitted for national calls, and the region code could be omitted for local calls. ===== GlobalNet Address Format ===== After much consideration I decided to use the IP-style dotted quad address. It only uses 4 bytes, lends itself to sub-netting and and has immense flexibility. If organised properly they can be used for routing, and will require only local co-ordination to prevent duplicates. I suggest that the address space be organised as country (dot) region (dot) router (dot) user, allowing up to 255 countries, 255 regions per country, 255 routers per region and 255 users per router. But this is not rigid; Each country could partition the space as it saw fit. We could use the existing ampr.org country and region codes. Thus in the address 131 dot 91 dot 245 dot 1, the 131 would represent the UK, and 91 is north Worcestershire. These addresses would be fairly easy to remember, as parts of them could be guessed, but it is far easier to remember a callsign or a name such as google.com, so the GlobalNet system will eventually include some form of name to address translation using a distributed database. ===== Routing Table ===== At the moment, GlobalNet routing is configured manually, just like simple IP routing. You have a table which contains GlobalNet addresses or partial addresses and the NetRom callsigns of the gateways which handle them. The only proviso is that the gateway must be in your nodes table. Destination Len Gateway 131.95.0.0 16 GB7GH 147.0.0.0 8 ZL2AQY-1 131.91.245.12 32 G8PZT-15 0.0.0.0 0 GB7BM In the above example, the first entry instructs the router to send region 95 traffic to GB7GH. The "len" figure specifies how many of the 32 address bits should be compared when making the decision. 16 means compare the top 16 bits, I.e. the first two bytes, and ignore the rest. My router doesn’t need to know anything about the stations in region 95, it just needs to know who can handle that traffic. The second entry tells the router to send all New Zealand traffic to ZL2AQY-1, and the third is a precise entry for one of my systems. The last entry in the example is a "default" route. Because I’m just a lowly out-in-the-sticks sort of router, I don’t know how to reach everywhere,... but I know a man who can. So I send everything else to him. Eventually the routing will be configured automatically. I did experiment 3 years ago with a system whereby GlobalNet routers could automatically discover each other and exchange routing information, but disabled it when someone complained it was keeping their link open. ===== GlobalNet Packet Format ===== 4 4 1 2 1-255 Bytes ----------------------------------------------------- | Dest | Source | TTL | PID | Payload | ----------------------------------------------------- All GlobalNet packets contain source and destination addresses, a Time-To Live counter, a Protocol Identifier, and a payload. The payload field can contain a variety of protocols, the most common being datagram protocol, stream protocol and control protocol. The protocol ID indicates the protocol used in the payload field. A GlobalNet packet is self-contained, and the only assumption made about the underlying protocols is that they can deliver complete, error-free packets. So GlobalNet can be transported within AX25 UI frames, AX25 virtual circuits, NetRom, IP and probably a lot of others. 7 7 1 1 1 1 1 1 12-236 bytes --------------------------------------------------------------------- | L3SRC | L3DST | L3TTL | 15 | 3 | FRG | FID | 0 | GlobalNet packet | --------------------------------------------------------------------- ^ protocol extension byte <------------------ Netrom header --------------> <---------------------------- Max 256 bytes ------------------------> The above diagram shows how GlobalNet packets are transported within NetRom packets. If the 20th byte of a NetRom header is set to 0 it indicates that the packet is not carrying Netrom layer 4, but some other protocol, indicated by the 16th and 17th bytes. The byte values 15 and 3 specify a GlobalNet packet. In that case, the bytes marked FRG and FID are used to control fragmentation, and are normally zero. ===== Streams and Standard Services ===== Netrom only allows one "service" per callsign, so you have to have separate callsigns (or SSIDs) for the node, and each application. Considering you might have the node itself, plus a chat server, BBS, DX Cluster, Callbook server, Weather service, PMS and so on, this quickly fills up the node tables. There is no standard for the SSID’s, so no way to know which callsign connects to which service. GlobalNet allows up to 65,536 circuit-based or *stream* services on each node, and the same number of outgoing connections. Thus we could define standard service numbers for BBS’s, PMS’s chat servers etc. and still have plenty spare. ===== Datagrams ===== Not all communication is connection-oriented. Sometimes, as in text messaging and APRS tunnelling, to name but two of the many possibilities, it is desirable to transport a single, self contained message from one process to another through the network, without having to create a connection. Frustratingly for developers like myself, NetRom doesn’t provide such a service. The GlobalNet Datagram Protocol allows up to 65,536 datagram services per address. As with stream services there are plenty of numbers available to allow some to be standard services, such as name server, time server. ===== Control Messages ===== When NetRom can’t route a packet, it just silently dumps it, and the transport protocol keeps resending it until it finally gives up. This could take up to 8 minutes with the existing recommended L4 settings. One function of the GlobalNet Control Message Protocol is to immediately inform the sender if for any reason a packet can’t be routed. This enables the sender and/or upstream routers to take some action, such as informing the user or reorganising the routing. It also provides echo request and reply functions, which can be used to manually or automatically to trace the network and check for problems. ===== Project Status ===== Basic GlobalNet functionality has been present in Xrouter since mid 2001, but I haven’t done anything with it. There are several reasons why not, but the main one is that I haven’t had the time to document it properly, not even for myself. This is my first attempt at collecting all the scattered notes together. Without documentation I couldn’t expect sysops to understand the system, assign the addresses, and set up the routing. GlobalNet works, but there’s not a lot you can do with it at the moment because it’s not finished, and there’s not much routing in place yet. You can "ping" GlobalNet nodes in much the same way as you can ping IP systems, using the command GPING. And you can connect from one GlobalNet node to another by using the GlobalNet address in the CONNECT command. It has been tested between here and New Zealand, but we haven’t done any large scale tests yet, because very few people knew about it. The system is still experimental, and I might wish to change the packet format as experience is gained. I don’t want to to that, but at this stage in a project sometimes you just have to take bold steps. ===== Future Development ===== Although it’s perfectly possible to run a network using manual configuration, one of the strengths of the NetRom network is its ability to self-configure. So I want to build that sort of functionality into GlobalNet. Ultimately I’d like the sysop to have nothing more to do than enter his address. I also want to add name servers, so people can come up with weird and wonderful addresses for their systems, and not have to use the raw GlobalNet addresses. I have lots of ideas for applications, and of course the first one will be finish the SMS system, which was one the main reasons for developing GlobalNet in the first place. GlobalNet is all very well between nodes, but to reach its full potential we need to extend it out to the end users. We don’t want the end users to have to be NetRom nodes; that would be bad for the NetRom network and they don’t need that sort of complication in their software. Simply running GlobalNet within AX25 UI frames would be sufficient. The only difficult part of that would be getting a protocol number off whoever is in charge of them. Along with the client protocols I’d like to develop some open-source client software to stimulate others to have a go. I don’t want GlobalNet users to be tied to a particular node by their address. I propose to allow dynamic address allocation, so that the users can roam from node to node. There’s so much that can be done, and it will ultimately make the packet hobby much more fun. ===== Further Information ===== Project web site: http://pzt.org.uk/gnet/ Email: g8pzt@blueyonder.co.uk Packet: G8PZT @ GB7PZT.#24.GBR.EU Xrouter software: http://pzt.org.uk/software/ Xrouter Group: http://groups.yahoo.com/group/xrouter I’ve started a web site for this project, but it’s under construction at the moment. If you’re interested, keep pestering me by email or packet. You can get an old copy of Xrouter from my software site, or the latest versions from the Yahoo group. I haven’t updated the version on the software site simply because I haven’t had chance to put together a full release of the latest version.