[Cu-wireless] architecture proposal
David Young
dyoung at onthejob.net
Thu May 2 21:14:26 CDT 2002
Forget this proposal. Zach and I have come up with an architecture that
unifies our thinking. I will send it to the list, soon.
Dave
On Thu, May 02, 2002 at 05:51:01PM -0500, David Young wrote:
>
> 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
>
> _______________________________________________
> 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