[Cu-wireless] architecture proposal

David Young dyoung at onthejob.net
Thu May 2 17:51:01 CDT 2002


I propose an architecture. The rationale for this architecture is that it
will produce a medium-performance community network for 9 residents in
Urbana rapidly and inexpensively, thus proving to funding agencies that
we are competent, diligent, organized, and realistic.  The expense and
time for implementing this project is kept down by avoiding excessive
planning and labor, by keeping equipment costs low, and by avoiding
enormously complicated theoretical problems.

I propose a two-tiered architecture.  In the bottom tier are two or more
clusters of homes and businesses.  One home in each cluster serves as
a gateway to the other clusters through the top tier, which consists
of point-to-point links, one home to another, or point-to-multipoint
concentrators connected one to another by point-to-point links, cable,
or DSL. It depends where the clusters are located.

Homes in a cluster participate in an ad hoc network, each using
an inobtrusive device consisting of an inexpensive computer, one
radio, and any one of a number of different antennas. Each device runs
identical software. It is self-configuring. It routes and forwards for
its cluster. It provides a single Ethernet jack to the home. When I say
that it is inobtrusive, I mean that it makes no objectionable noises,
it does not disrupt AM radio reception, it does not take up a lot of
space, and it is not an eyesore indoors or outdoors.

Stations in a cluster are tuned to the same channel to ease stations'
discovery of one another and to ensure high connectivity. Stations in
the same cluster belong to the same subnet.

Stations in the top tier, if they are connected wirelessly, are tuned
to different channels than the stations in a cluster. Stations in the
top tier provide Internet connections.

Each station participating in the top tier and the bottom tier has a
"cluster side" and a "city side." The cluster side must provide identical
services to its cluster as any station in a cluster, but it also provides
an Internet gateway and a DHCP server. The city side runs whatever you
please.  The city side and the cluster side of a station participating
in the top tier may be connected by a wireless/wired network.

No station may advertise its connection to the Internet if it does not
participate in the top tier. The reason is that there should be reliable
coordination of stations with Internet connectivity, and I think that
the most reliable connections will occur in the top-tier.  I will not
explain the coordination here.

Stations in a cluster find out their IP number using a DHCP client.
Until a station has found out its DHCP server and its IP number,
it provides no service. When a station has found out that info, it
relays DHCP requests from its neighbors (speaking radio-wise) to its
DHCP server. Only top-tier stations may run a DHCP server.  (There is
probably a master DHCP server on one top-tier station and DHCP relays
in every other top-tier station.)

The community network is 10/8. It is NAT'd to routable addresses
by top-tier Internet gateways. Networks 10.0.x/24 are the clusters.
Network 10.1/16 is the top-tier network. Networks 10.2/16, 10.3/16, etc.,
are reserved for future allocation to new clusters, to wireless mobility,
and to the top-tier.

Stations in a cluster run OSPF. So do top-tier stations. In a cluster,
most stations contain routes like these, where wi0 is a wireless
interface:

station 10.0.1.5
------- --------

   dest/mask      | nexthop                  | metric
   ---------------+--------------------------+-------------
   0.0.0.0/0      | 10.0.1.1 (interface wi0) | 1
   0.0.0.0/0      | 10.0.1.2 (interface wi0) | 1
   0.0.0.0/0      | 10.0.1.7 (interface wi0) | 3
   10.0.1.1/0     | 10.0.1.1 (interface wi0) | 1
   10.0.1.2/0     | 10.0.1.2 (interface wi0) | 1
   10.0.1.7/0     | 10.0.1.7 (interface wi0) | 3
   10.0.1.9/0     | 10.0.1.7 (interface wi0) | 1

A top-tier station participating in a cluster has these routes:

station 10.0.1.1 (aka 10.1.0.13)
------- -------- ---- ----------

   dest/mask      | nexthop                   | metric
   ---------------+---------------------------+---------
   0.0.0.0/0      | 10.1.0.1 (interface wi2)  | 3
   0.0.0.0/0      | 10.1.0.2 (interface wi1)  | 1
   10.0.2/24      | 10.1.0.1 (interface wi2)  | 3
   10.0.3/24      | 10.1.0.2 (interface wi1)  | 1
   10.0.5/24      | 10.1.0.2 (interface wi1)  | 1
   10.0.1.2/32    | 10.0.1.2 (interface wi0)  | 1
   10.0.1.2/32    | 10.0.1.7 (interface wi0)  | 2
   10.0.1.5/32    | 10.0.1.5 (interface wi0)  | 1
   10.0.1.7/32    | 10.0.1.5 (interface wi0)  | 1
   10.0.1.7/32    | 10.0.1.7 (interface wi0)  | 3

However, if that station is back-to-back stations connected by Ethernet,
it has these routes on its "cluster side," where fxp0 is a wired Ethernet:

station 10.0.1.1 (aka 10.1.0.13)
------- -------- ---- ----------

   dest/mask      | nexthop                   | metric
   ---------------+---------------------------+---------
   0.0.0.0/0      | 10.1.0.1 (interface fxp0) | 3
   0.0.0.0/0      | 10.1.0.2 (interface fxp0) | 1
   10.0.2/24      | 10.1.0.1 (interface fxp0) | 3
   10.0.3/24      | 10.1.0.2 (interface fxp0) | 1
   10.0.5/24      | 10.1.0.2 (interface fxp0) | 1
   10.0.1.2/32    | 10.0.1.2 (interface wi0)  | 1
   10.0.1.2/32    | 10.0.1.7 (interface wi0)  | 2
   10.0.1.5/32    | 10.0.1.5 (interface wi0)  | 1
   10.0.1.7/32    | 10.0.1.5 (interface wi0)  | 1
   10.0.1.7/32    | 10.0.1.7 (interface wi0)  | 3

The reason for the /32 routes is that not every node in a cluster need
not be in radio range of every other node, so some nodes in the same
cluster will route through each other.

Questions? Comments?

Dave

On Thu, May 02, 2002 at 02:21:32PM -0500, Jon Dugan wrote:
>   I apologize for missing the Tuesday meeting, I had plans the predated the
>   change to Tuesdays.  I will be there not the next Tuesday (out of town on
>   business) but the following Tuesday.
> 
> On Thu, May 02, 2002 at 07:53:24AM -0500, The Morenz Family wrote:
> > >From: David Young <dyoung at onthejob.net>
> > 
> > >I can understand the desire to keep the routing tables compact, but subnet
> > >routing seems unnatural for a wireless network. Will OSPF bog down if
> > >we do not use subnets? Every host in a subnet needs to be individually
> > >routed, anyway....
> 
>   Why does every host in the subnet need to be routed individually?  I am
>   trying to understand what problem you are trying to solve/what the
>   architecture you are building toward.
> 
> > The whole idea of subnet routing is that things in a subnet are not
> > individually routed.  So, if you are individually routing to the
> > elements of a subnet then you are not using subnet routing.  Am I
> > missing something?
> 
>   No that is absolutely correct.  Routing works in the following manner, there
>   are three components to a route table entry:
> 
>     1. the network address
>     2. the mask
>     3. the next hop
> 
>   The network address specifys the high bits of interest.  The mask specifies
>   how many of those bits are interesting and the next hop determines what the
>   next hop router is (that is the next Layer 3 device).  
> 
>   So for example, NCSA has the 141.142.0.0/16 block of address space.  The /16
>   notation means that the higest 16 bits make up the legitimate prefix.  This
>   is equivalent to a 255.255.0.0 netmask.  A network address with a mask is
>   often referred to as a prefix.  A /24 is the most typical length for a
>   subnet, it has a netmask of 255.255.255.0.
> 
>   Routes are always matches in longest prefix order, that is if you are trying
>   to forward a packet to 141.142.2.2 and you have the following two routes:
> 
>     Prefix          Next Hop
>     --------------  ----------------
>     141.142.0.0/16  141.142.x.y
>     141.142.2.0/24  141.142.a.b
> 
>   You will select the second route because it has a longer prefix.  However,
>   for example outside of NCSA we only announce the /16.
> 
>   I'm not sure what the current proposed architecture is, however it seems
>   reasonable that you would want to use subnet routing.  If we use the RFC
>   1918 address space 10.0.0.0/8 and dividie that up amongts the various nodes,
>   we should have plenty of room for growth.  We could allocate a /16's to major
>   aggregation point which would hand out /24's to their downstreams.  This is
>   essential the same as the BxNode and CxNode from the Seattle Wireless stuff.
> 
>   In this sort of a model, the CxNodes would advertise their connected subnets
>   into OSPF.  Each BxNode would collect all the routes from their downstream
>   Cx nodes and exchange routes with other Bx nodes.
> 
>   I have given some thought to a routing architecture, but I'm afraid I'm out
>   of time right now (the day job calls).  
> 
>   One last question which routing protocol implementation did you have in
>   mind?  GateD?  Zebra?
> 
> > My understanding is that a few thousand entries in the routing table
> > is no big deal.  Millions are a problem.  Are you talking about just
> > Champaign-Urbana?  If so, what is the point of subnet routing?
> 
>   Correct.  We really don't need to worry about the size of the routing table
>   until it gets into the 100,000 range or so.  A P133 can handle stuff under
>   100,000 routes with no major problem.
> 
> > ####(THERE SEEMS TO BE SOME CONFUSION REGARDING ROUTING; "SUBNET 
> > ROUTING" IS A REDUNDANT TERM. ALL LAYER 3 PACKET SWITCHING IS DONE BY 
> > NETWORK (OR "SUBNET") NUMBER. ROUTERS DO NOT, IN FACT *CAN NOT* CARE 
> > ABOUT HOSTS...THEY ONLY ROUTE TO NETWORKS.)
> 
>   A router can in fact provide a route to a single host.  You can specify a
>   route with a mask that is 32 bits long.  This route will cover a single
>   host.  This is known as a host route or a /32.
> 
> Jon
> -- 
> Jon Dugan             |  Senior Network Engineer, NCSA Network Development
> jdugan at ncsa.uiuc.edu  |  269 CAB, 605 E Springfield, Champaign, IL 61820
> 217-244-7715          |  http://www.ncsa.uiuc.edu/~jdugan/
> 
> _______________________________________________
> Cu-wireless mailing list
> Cu-wireless at lists.groogroo.com
> http://lists.cu.groogroo.com/cgi-bin/listinfo/cu-wireless

-- 
David Young             OJC Technologies
dyoung at onthejob.net     Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933




More information about the CU-Wireless mailing list