[Mep-dev] MEP as an IP Network

[Bob McGwier]

-----Original Message-----
From: mep-dev-admin@uppermeadow.com [mailto:mep-dev-admin@uppermeadow.com]
On Behalf Of Timothy J. Salo
Sent: Tuesday, December 02, 2008 1:53 PM
To: mep
Subject: [Mep-dev] MEP as an IP Network

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).


>>>  This was just about where I was going to ask  WHAT IS THERE TO BE DONE?


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.

>>> Why isn't this completely trivial?  We use a private address space
(since I don't think our class A public addresses will ever fly <<pun
intended>>) and we assigned these addresses to specific 
>>> callsigns and allow reverse lookup. This is subject to abuse but I can
get on CW today and shock the heck out of the world by signing KA9Q in morse
at 40 wpm now can't I?  This allows us to serve up >>> IP addresses from DNS
when we lookup n4hy.amateuradio.org.  This requires NO change of IP protocol
and is KISS.

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.


-----  snip -----

It may be a weak system, and what I am suggesting may be even weaker but
they have the virtue of being reasonably simple to implement and not
requiring tons of develop on top of IP.  I agree we do not want to use
AX.25.  It was kludge to break link layer isolation and add pseudo
routing/gateway/networking manually.  We pick a link layer that works and do
the rest with encapsulation.

-tjs

73's
Bob



ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom