<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Everyone take a deep breath before
reading the thread. There is conflict ahead, but we knew that.
Read it only if you're willing to take the view that what is
written is done so under the best possible intentions.<br>
<br>
<br>
On 03/12/2013 03:04 PM, ZPO wrote:<br>
</div>
<blockquote
cite="mid:CAJVHAXprSPhuKiUAV2n9ofq-QWZzi8FXUn+1Ssb5F-9gweCryg@mail.gmail.com"
type="cite">
<pre wrap="">Quick note before I get dragged back into work....
Bart is correct that MESH has been overloaded as both a name for a
topology and a proper noun for a specific implementation of a MANET.
As long as we know what we're talking about, we can use either term.
We can call it MANET which is technically accurate, or MESH since that
is commonly used and understood.
</pre>
</blockquote>
<br>
I'm glad we agree on at least that. :) Let's stick with MESH in
all caps when referring to NW-MESH type stuff, since MANET can also
mean a network like HamWAN and we'd once again be ambiguous.<br>
<br>
<blockquote
cite="mid:CAJVHAXprSPhuKiUAV2n9ofq-QWZzi8FXUn+1Ssb5F-9gweCryg@mail.gmail.com"
type="cite">
<pre wrap="">
I view the NW-MESH and HamWAN projects as complimentary. HamWAN in
general and the PSDR component in particular makes an excellent
backbone transport network to move data around the wider area.
NW-MESH works well to cover the last mile. </pre>
</blockquote>
<br>
This is where I think HamWAN is being sold short, since it also
works great on the last mile. Reason being is HamWAN sites are all
planned to be non-ground-level, so LoS probability increases which
makes last mile happy. Your trip may be physically longer by a few
miles, but the latency and speed will still be good, if not better
when compared to multiple ground hops for the same distance. In
close-proximity situations, the end-user-site to end-user-site
direct connectivity of NW-MESH I believe provides an optimization.
A COUPLE hops of MeSh might indeed be superior to traversing a busy
sector.<br>
<br>
<blockquote
cite="mid:CAJVHAXprSPhuKiUAV2n9ofq-QWZzi8FXUn+1Ssb5F-9gweCryg@mail.gmail.com"
type="cite">
<pre wrap="">Full bidirectional
interconnection of the networks has some significant challenges as
Bart states. They are surmountable, but there are some issues to
address.</pre>
</blockquote>
<br>
I'm glad we both recognize this fact.<br>
<br>
<blockquote
cite="mid:CAJVHAXprSPhuKiUAV2n9ofq-QWZzi8FXUn+1Ssb5F-9gweCryg@mail.gmail.com"
type="cite">
<pre wrap=""> On the other hand, using the PSDR as a transport means for
interconnecting pockets of NW-MESH is not terribly difficult and can
be done rather simply.</pre>
</blockquote>
<br>
It sure can! But read on to the last point.<br>
<br>
<blockquote
cite="mid:CAJVHAXprSPhuKiUAV2n9ofq-QWZzi8FXUn+1Ssb5F-9gweCryg@mail.gmail.com"
type="cite">
<pre wrap="">
I greatly prefer to keep the projects separate and have a
collaboration on the interface between the two efforts outside the
mainline work of either. The projects have differing goals, differing
timelines, and differing concepts.</pre>
</blockquote>
<br>
And I'd greatly prefer to merge the projects, because I'm not
convinced that we do have differing goals. If our goals can be
communally stated as "provide the amateur radio community with a
fast wide-area multi-megabit IP-based digital network that can scale
and out-last either of us", then I think we have a chance at
merging, because that's pretty much the HamWAN mission statement.
For the more detailed version, see the <a
href="https://www.hamwan.org/t/tiki-index.php?page=Constitution&structure=HamWAN">official
HamWAN mission statement</a>, which is the first article of our
constitution.<br>
<br>
This is where I think you, Rob, and the rest of the NW-MESH team
need to get together with the HamWAN people to spell out exactly
what it is that each of us is trying to accomplish. Do you have a
mission statement you can share? Do you have a favorite low-noise
public meeting location with power + wifi? Starbucks is sounding
likely.<br>
<br>
<blockquote
cite="mid:CAJVHAXprSPhuKiUAV2n9ofq-QWZzi8FXUn+1Ssb5F-9gweCryg@mail.gmail.com"
type="cite">
<pre wrap=""> I'd like to see some more detail
from Bart on what he sees as the large issues with bidirectional
interconnection (I think I know most of them) or simply using the PSDR
as transport via tunneling between access nodes.
</pre>
</blockquote>
<br>
So even though it's possible for HamWAN to act as a dumb pipe for
NW-MESH, this is not a fair arrangement for HamWAN. If this were a
peering agreement at an Internet exchange, it would be considered a
violation of the terms of service set out in every Internet exchange
I'm aware of. A fair peering agreement is where each network moves
equal amounts of data to and from a peer, where said traffic is
between clients of each network. This means not via a peer network,
and the traffic is from/to clients of the same originating network.<br>
<br>
With BCWARN, it's easy. We each cover different regions, we each
come to the game with our own backbone transport, so we are indeed
peers and can exchange traffic as such with no ill feelings. BCWARN
also uses OSPF/BGP and public IP addresses, which simplifies matters
even more. They also have restrictions in place as to who can
participate so we're not carrying questionable traffic on HamWAN.
In short, all the bases are covered and we're happy to peer.<br>
<br>
I'd rather not spell out the NW-MESH incompatibilities with networks
like BCWARN and HamWAN in this email, simply because I don't feel
qualified. I'll need to ask questions in order to fully explore the
subject. This is where I think it makes sense to have a meeting
between our groups and hash these technical things out. Off the top
of my head, the attributes of using 10/8 space is a problem since it
can conflict with people's home networks (and other reasons), as is
the access policy since as far as I know any non-ham can just get
the key and join a NW-MESH node. Correct me if I'm wrong.<br>
<br>
Hell, I don't even know if NW-MESH is running part 97 or part 15
rules. What say you? :)<br>
<br>
--Bart<br>
<br>
<br>
<blockquote
cite="mid:CAJVHAXprSPhuKiUAV2n9ofq-QWZzi8FXUn+1Ssb5F-9gweCryg@mail.gmail.com"
type="cite">
<pre wrap="">
73-KY9K/Brian
On Tue, Mar 12, 2013 at 2:16 PM, Bart Kus <a class="moz-txt-link-rfc2396E" href="mailto:me@bartk.us"><me@bartk.us></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Craig,
First, let's speak the same language.
There's a lot of confusion around the word "MESH". I'm also not sure why
it's always capitalized. It's not an acronym as far as I know. The term
"mesh network" describes nothing more than the logical topology of a
network. There's a really good write-up on this at the wikipedia page. I'm
pretty sure that when you (and others on this email) use the phrase "mesh
network" it is not the wikipedia definition you're intending. It means
something different, including:
1) Using a common RF channel
2) Promiscuous neighbor discovery + association
3) Automatic IP configuration based on MAC
4) Nearly open node authentication
5) Omnidirectional operation
6) WDS-style operation
These are the typical traits of a SeattleWireless style mesh network (which,
BTW, has been attempting to bootstrap itself for the last 13 years). This
type of definition of "mesh network" is quite a different animal from the
canonical mesh network definition (wikipedia's, derived from network
theory).
The reason I want to make the distinction clear is that nearly all large
networks in the world are indeed mesh networks, but nearly none of them
possess the qualities of 1-6. So when I say something like "HamWAN is a
mesh network", I want it to be clear that I'm referring to the network
topology only (the wikipedia definition). I'm not sure what is the right
word to describe the other type of network; perhaps capitalizing all the
letters is a good differentiator after all. :)
So, with the definitions out of the way, let me address your actual email
now that I can speak to it unambiguously.
I concur that we all want to implement a mesh network, but I don't think
everyone wants to implement a MESH network. Phrasing the problem of "how do
we provide modern digital communications to the ham community" in terms of
"how do we implement a MESH network" is putting the cart before the horse.
Over the last 6 months, I've been leading the HamWAN effort to create
solutions to the first question. We've made respectable progress on both
the RF engineering and networking fronts. We had a fully functional cell
site setup @ last weekend's Flea Market. This site design is about to start
rolling out to the real world.
This transition in the project's status has allowed me to start thinking
about how HamWAN might integrate with other ham networking efforts. We've
had a good relationship with BCWARN.net for the last few months, and
integration with that network will be simple. The physical links are
already planned in fact! We're both excited to make it happen and start
exchanging traffic internationally!
The integration with NW-MESH efforts is far more challenging. In fact, it
may be outright impossible unless changes are made in the NW-MESH design.
>From what I've seen, this difficulty of peering will be present in all MESH
networks. The problems range from simple route exchange, to address space
conflicts, to policy propagation (access, QoS, filtering, etc). I don't
even wanna think about DNS. :P
Having said all that, there is some value to HamWAN using a MeSh (hybrid of
mesh and MESH) layer. Traffic between nodes may flow more optimally on the
ground than through the mountain sites. A nearby ham who doesn't want to
invest in a dish might get on HamWAN by MeShing with his neighbor. I'd be
good for the health of HamWAN to make use of these optimizations. But like
I said, in order for these routing decision to be made correctly and
automatically, NW-MESH designs will need to change.
I'd like to invite you (in fact, all of you) to join the HamWAN weekly
meeting today @ 7PM. I'll re-send the connectivity details on the mailing
list (email: <a class="moz-txt-link-abbreviated" href="mailto:psdr-join@hamwan.org">psdr-join@hamwan.org</a>) an hour before the meeting, but basically
install Mumble 1.2.4+ (currently beta), and connect to BartK.us. Please use
a headset to avoid generating echoes.
Craig, can you give me an idea of your skills? Perhaps you would enjoy
solving these types of problems as part of the HamWAN development team? We
run a tight ship with specific assignments and weekly reporting. I believe
this is the "small group of experts" approach you were proposing. :)
--Bart
On 03/12/2013 12:09 PM, Craig B wrote:
When I first heard about the MESH project from Daniel Stevens (KL7WM) back
in late fall 2012, the first question I had for him was "what will it
connect to?" Since then, as I have become more involved I have started to
formulate what I think it could be connected to and how it could be used.
Based on what I have learned and seen to date, I see 3 tiers of network
involved here. The backbone, which I see as a long-haul that would be based
on a region that is defined by terrain and distance. The middle tier would
be smaller and could be between HAM towers or other "secondary" sites. The
3rd tier would be for the "neighborhood" or "home" MESHing with WRT's and
other low-power devices. In this type of configuration, I see the backbone
as being the one common piece across regions while the secondary and
tertiary tiers could be specific to the 'regional' implementation. Each
tier would have to bridge from itself to the next level, which seems to be
reasonable where a given site could choose to bridge by adding necessary
hardware or remain remote.
What I would like to do is see if we can't get a written network plan for a
regional backbone and then any additional tiers that need to be included in
a good network design document. I am a firm believer that it should be
hardware agnostic for the most part, although could provide a list of
acceptable components that have been shown or believe to be the best
hardware based on application. It would also dictate how traffic might be
handled moving up/down through the tiers, possibly allowing for QoS or other
transport methods.
As I am sure we all want to see a MESH network available to all HAMs; given
the area NW-MESH has been getting feedback on, I think we need to start
looking at how we connect them all together. As such, in talking with Bob
Rutherford, it seems like the first step is to build out a plan that could
be presented to FWARC, Tukwila Radio Club, and EMCOMM (and other
clubs/groups).
Since this is all great in theory, it seems the next step is to secure
funding and move it from paper to reality. Given the real application of
this MESH network for EMCOMM, and their generally deep pockets, it seems
like a great way to get a backbone built.
If we are going to design this, I believe it needs to be initially designed
by a small group of network and radio experts. Once an initial plan is
cobbled together it could be released to the larger MESH community for
comments and additions/subtractions, etc.
I am willing to take on leading this charge; however, I will need a team of
experts behind me helping lay the ground work. My initial thought is to
have something ready by mid or late summer, given that we all have other
priorities as well, not adverse to taking longer if it means having a
complete and well planned out design.
Any thoughts on this?
Thanks,
Craig
KF7LLA
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<br>
</body>
</html>