Online Amateur Radio Community Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Packet White Paper: 109\\ 
Paula Dowie\\ 
July 2001\\ 

====== NET/ROM DATA MULTIPLEXING ======

===== STATUS OF THIS MEMO =====

This document proposes a simple extension to the NET/ROM layer 4
transport protocol, allowing up to 65536 different types of "service"
to be hosted on a node, using a single Secondary Station Identifier.


===== TABLE OF CONTENTS =====

1. Introduction\\ 
2. Motivation\\ 
3. Discussion\\ 
4. The Proposal\\ 
5. Packet Format\\ 
6. Receive Processing\\ 


===== 1. INTRODUCTION =====

In order to provide multiple "services" on a single Net/Rom node, each
service (e.g. BBS, PMS, Chat server, Dx Cluster, HTTP, Game server etc)
requires a different Secondary Station Identifier (SSID).

As there are only 16 possible SSID's, and therefore services, per node
callsign, this limitation could stifle future development of novel
services.

Additionally, every service that is to be Net/Rom L4 connectable must
have an entry in the NetRom "Nodes table", and those entries must be
propagated via nodes broadcasts. Just 20 nodes, each with 8 services,
would use a total of 160 entries. A table of that size is slow to
propagate over RF links, making it difficult for the network to achieve
stability. It is also cumbersome for users to view.

Finally, there is no agreed standard for SSID numbers, and the "Aliases"
often give no clue to what service is associated with it.

This document proposes a fairly trivial solution to the above problems.
If implemented, it would allow vastly more services to be carried over
Net/Rom, with standardised service addresses, and zero cost to the nodes
table size.


===== 2. MOTIVATION =====


The primary motivation for this proposal was a desire to allow novel
services, such as HTTP, SMS, APRS, gaming and File transfer, to name but
a few, to be transported over the Packet Radio network. However, it may
also help alleviate other problems, as explained below.

Over recent years, thanks to better connectivity, and new software which
allows larger nodes table sizes, the amount of routing information being
moved around the network is increasing rapidly. This is consuming
valuable bandwidth, and if the trend continues, modelling suggests that
the network will fail to converge to a stable, accurate state after a
perturbation. By the time the last "nodes broadcast" packet has been
sent, the table is already out of date.

If a node user issues a N(odes) command, it may take several minutes to
transmit the whole nodes table over congested RF links, and it has been
observed that many users simply disconnect rather than wait for the
whole table.

A typical nodes table may contain multiple entries for the same node,
each with a different alias and SSID, one for each service hosted by
that node. There is no consistent standard for these addresses, leading
to confusion, and wasted connections.

As more services are added, this situation can only get worse, but this
proposal offers a mitigation. 


===== 3. DISCUSSION =====


Although Net/Rom may not be the BEST networking protocol, it has stood
the test of time and, despite the availability of a formal protocol
specification, has become the de facto standard for AX25 networking.
Any attempt to replace Net/Rom would probably be doomed to failure.

In order to expedite the development of novel services, a way must
therefore be found to transport them over Net/Rom, without breaking
anything.

In contrast with NetRom, which only allows one service per address
(i.e. callsign-SSID), with only 16 possible addresses per node, TCP and
UDP allow up to 65536 different services per IP address. Furthermore,
the important service numbers are well known and standardised.

It is unlikely that Packet Radio would ever need to support as many as
65536 different services per node, but there is certainly a need for
more than 16.

Using TCP-like "service numbers" rather than SSID's would allow both
simplification of the nodes table, and standardisation of the numbers.
For example, service 0 could be a normal connection to the node's
command line, service 1 might be an information server, service 2 could
be the sysop's PMS, service 21 might be file transfer, and service 80
could be an HTTP server.

So why not simply use TCP/IP over AX25?

TCP/IP is a verbose protocol, which does not work well over low
bandwidth, unpredictable RF links. In addition, it requires
co-ordination, and knowledge that many sysops do not posess, nor wish
to posess. It has its niche, but on radio links will never displace
NetRom.

NetRom needs to be more like TCP/IP, without being TCP.

<code>

	[large chunk missing/corrupt here!!]

</code>

The service port number is only required during circuit set up. After
that, the circuit numbers (along with callsigns) are sufficient to
maintain the circuit.


===== 4. THE PROPOSAL =====


The proposed solution is to add an "extended" connect request to the
list of NetRom L4 opcodes. This request would include the target
service number. The suggested mnemonic is CREQX.

Such a packet should pass unmolested through intermediate L3 routers,
because the L4 header is of no concern to L3. It should in theory be
ignored by legacy L4 endpoints, if they are correctly written according
to the "Robustness Principle".

Why Add Another Opcode?

There is a "reserved" flag in the opcode/flags byte, but the NetRom
designers may have earmarked that for future use, so we can't use that.

Additional bytes could be appended to a normal CREQ, but that might
break other people's software.

So the safest option is to add another opcode.

The proposed opcode for CREQX is 8, and the unused sequence number
fields of a "regular" CREQ could carry the requested service number,
as shown in the following comparison netween CREQ and CREQX:


===== 5. PACKET FORMAT =====


The following diagrams depict only the transport header portion of a
Net/Rom frame. The layer 3 header is not affected by this proposal.

Normal CREQ:

<code>
   ----------------------------------------------------------
   | id | ndx |   unused    | 1 | win | usercall | nodecall | 
   ----------------------------------------------------------
     1     1        2         1    1      7           7  Bytes
</code>

Extended CREQ:

<code>
   ----------------------------------------------------------
   | id | ndx | svch | svcl | 8 | win | usercall | nodecall | 
   ----------------------------------------------------------
     1     1     1      1     1    1      7           7  Bytes
</code>

Where id and ndx are the senders circuit ID and index as usual, svch
and svcl are the high and low bytes of the target service number, 8 is
the new opcode, and the remainder is as normal.


===== 6. RECEIVE PROCESSING =====


Upon receipt of CREQX, the receiving node checks whether or not the
requested service is available. If it is, a CACK is sent in the usual
way, and the connection is identical to "normal" NetRom.

If the requested service is not available, unimplemented or busy, the
connection is rejected using the CHOKE flag in the usual way.