[Mep-dev] MEP as an IP Network

[Timothy J. Salo]

Michelle wrote:
> I strongly agree with the goal of making MEP a fully functional 
> IP network. That is the baseline assumption, and should be explored, 
> challenged, and talked about until we are more than fully convinced it's 
> the right thing to do, where "it" is well-defined. This leads directly 
> to identifying the requirements for fully supporting IP.

I'm sort of working on it.  My AMSAT 2008 paper is a start.
An MEP interface specification that describes how the MEP
interfaces with its users will be a fundamental document.

My objective is that the MEP be indistinguishable from other
IP networks.  It should connect to both devices (e.g., a
personal computer) and networks (e.g., a home network or
even the Internet).

Doing this well requires more than simply forwarding IP
packets.  For example, RFC 1812, the original  "Requirements
for IP Version 4 Routers" is 175 pages long.  Plus, it is
incomplete and probably wrong in places.  One significant
implication of this is that we should think about whether
the remote/ground stations ought to (or must) run a traditional
operating system, such as Linux (or an embedded Linux variant).
This would enable the MEP to leverage a large body of existing
software.

> What are the repercussions of amateur radio communicating over a 
> fully functional IP network? What possibly unexpected requirements do we 
> incur upon ourselves by doing so? Are authentication and security and 
> identification controversial issues, or are they now so embedded in the 
> communications ecosystem that to remove these functions would be 
> negative?

I'm probably sure what the questions are, but...

The one unique requirement I can think of is the need to
identify the transmitting station.  AX.25 decided to use
call signs for both station identification and routing.
As a result, AX.25 doesn't interoperate with anything else.
I believe that the MEP ought to route on IP addresses and
add text-based station identification somehow.

For regulatory station identification purposes, one could
simply put the station identification in an IP option.
This is transparent to IP networks (well, except for ISPs
that discard packets with options, because IP options all
but break commercial routers).  This "station identification"
should be a text string that is transparent to the MEP.  It
might contain a call sign.  It might contain other information.
But, to the MEP it is simply an opaque text string.  And, the
MEP should know how to translate between these station
identification text strings and IP addresses, as described
below.

> Is the transport protocol truly unaffected by the type of 
> traffic, which is a hallmark axiom of layered protocols? In other words, 
> is there anything in particular about amateur radio that would cause a 
> change in the requirements for IP?

The notion of a universal protocol that transports everything
has been around for a while.  In the 1990s it was ATM, which was
supposed to carry voice, private lines, video, and data.  IP has
pretty much taken over as the universal protocol.  Perhaps,
the biggest challenge for the MEP and the ACP is to handle
the short packets used by voice gracefully.  But, I think this
is an FEC issue, not an IP issue.

> Searching, rooms, filters, friends lists, 
> modeling, quality of service, and other fun things that are enabled by a 
> rich set of metadata certainly start to sound a lot like "accounting". 

I don't know what "searching, rooms, filters, friends lists"
are, but they all sound like applications that might use the MEP,
rather than functionality that should be provided by the MEP
(which, I claim, ought to be an IP network).  I think about all
these applications need from the MEP is a way to translate
between text station identifiers and IP addresses, and a way
to know the station identifiers of the active stations.  I
think that hosts should be able to use the DNS to perform
this translation.  The MEP remote/ground station ought to
provide a DNS resolver.

> Do you (all) think that the the lack of pressure to make the service pay 
> for itself (as opposed to possibly trying to make the hardware come in 
> at cost) might make any difference to the design choices of the 
> protocols and the link?

Probably not if we start with an IP network as a model.

> Most of the examples that I am familiar with spend a lot of time on 
> accounting. Most of the satellite models and most cellular models have 
> to keep track of users and how long and how much they use the link, in 
> order to charge for it and make money. 

See above.

> My first inclination is that the deletion of all the accounting 
> overhead would do two things - it would require some redesign of the 
> link, and it would possibly increase performance due to a lessening of 
> complexity.

I doubt it, but would be happy to have someone explain how I
am confused.

> The level of accountability (authentication and security) needs to be 
> explored and discussed. How concerned should we be with harmful or 
> unauthorized use?

At the RF level, you are probably out of luck.  You can't prevent
people from transmitting.  A rich set of strong authentication
and security capabilities are available with the Internet protocols.
We should use them, rather than invent new ones.

> A model to consider is D-Star, which 
> has repeater registration by call sign. This is a user-entry ID. So, to 
> me, it is the equivalent of stating your call sign on the air and 
> remains a voluntary, honor-system act.

As I understand it, this is a very weak system.  We ought to
use cryptograpically based systems when we want to authenticate
parties.

-tjs