* Introduction [1]
* Logical view of different nodes: [2]
* Client Nodes [3]
* Dx Node [4]
* Cx Node [5]
* Bx Node [6]
* Ax Node [7]
* Variations [8]
* Bx Cx Hybrid [9]
* Re-trans [10]
* Hypothetical example [11]
* Link types [12]
* Antennas for links [13]
* Protocols for links [14]
* BSS [15]
* WDS [16]
* Bridge [17]
* IBBS [18]
* Node Examples [19]
* RGInnerNorth [20]
* Southern [21]
* Dandenong Foothills [22]
* Implementation of a Node [23]
* Linux PC based node [24]
* Laptop based node [25]
* Dedicated Appliance [26]
* AP based node [27]
* Multi-band AP [28]
* Implementation pricing comparison [29]
* Other considerations [30]
* AP bridging vs. routing [31]
* Public segment [32]
* Using VLANS on your WRT54G [33]
INTRODUCTION
While the wireless network in Melbourne is in it's infancy other
communities have very well developed infrastructure. In the US
community networks are not necessary providing an alternative network
to the ISP provided ones but are rather providing wireless access for
community members whereever they are.These networks are successful as
there is no bandwidth limits from the regular ISP's and every coffe
shop is able to hook up a DSL modem and an AP to become a node.
In the well developed "geek" centres (Bay Area, Seattle, Austin among
others) the local wireless orgs assist the setup of nodes to enlarge
the coverage of the network. That's not to say they don't build
backbone infrastructure as it is also high on their objectives but
citywide access for members seems to be the driving factor.
Here in AUS it's a little different as the lack of competition means
that most ISP's still gouge their customers and apply fairly draconian
conditions (about what you can hook up, sharing your bandwidth, etc.).
The Melbourne Wireless network is pretty fragmented at the moment.
There are pools of linked nodes but no city wide backbone yet. That
seems to be the primary goal for the group at the moment. Creating a
backbone is very dependant on individuals that want ot be part of it.
So what is a node and do you have one yet?
Seattle Wireless probably has the best classification of node types:
* Client Node
* Dx Node
* Cx Node
* Bx Node
* Ax Node (or Super Bx Node)
These node definitons really need to be applied a bit loosely as in
reality a node will start out as one type and morph into a different
type depending on the availability of other nodes to link to. Perhaps
the most common variation would be a hybrid Bx-Cx that would have
links to other nodes and support either Client Nodes or Cx Nodes on
the BSS interface.
Another common evolution would be a node that starts out running a
BSS interface and has a number of other nodes pointng their uplink
links to it. In this case the links may be sub-optimal but are likely
to suffice for the amount of traffic and usage of the connected nodes.
(Note that as the discrete areas of connectivity coalesce and the
network becomes used more that these types of "shared" connections
will become bottlnecks in the network).
LOGICAL VIEW OF DIFFERENT NODES:
CLIENT NODES
A Client Node is a node that connects to a Dx Node or Cx Node,
typically using BSS mode. It could be a PC, laptop or handheld device.
A Client Node could be fixed or mobile.
DX NODE
Dx Nodes is a node without any upstream connection, this is typically
the node you install at home when you want to get wireless in your
house. It allows your wireless devices to be part of your home LAN and
you may have internet access for your own personal use. In this
scenario you keep the node closed and may use some form of encryption
(weak though it may be).
+-----------------+ | | | | | +-----+ | | BSS |---/--- to Client
Nodes | +-----+ | | | | +-----------------+
CX NODE
Cx Node is a node with one upstream connection. A Cx Node connects to
a single Bx Node. The CxNode [34] accepts connections from Client
Nodes and routes thouse requests to it's upstream connection. At this
level routing is easy. The Cx Node is the on-ramp to the local
wireless network.
+-----------------+ | | | | | +------+ | | BSS | ---/--- to Client
Nodes | +------+ | | | +------+ | | IBSS | +++++++++ to upstream Bx
Node | +------+ | | | | +-----------------+
BX NODE
Bx Nodes support a pool of Cx Nodes and have two links to other Bx
Nodes provides DHCP to the client Cx Nodes and intellegent routing. So
a Bx Node has 3 radios, one for supporting the Cx Node pool and two
more for making redundant links to the rest of the backbone using two
other Bx Nodes.
+-----------------+ | | | | | +------+ | | BSS | ---/--- to Cx Nodes
| +------+ | | | +------+ | | IBSS | +++++++++ to peer Bx Node |
+------+ | | | +------+ | | IBSS | +++++++++ to peer Bx Node |
+------+ | | | | +-----------------+
AX NODE
Ax Nodes or Super Bx Nodes have more then 3 radios and tend not to
support a client cloud ( no Cx Nodes hanging of it). It provides
routing between it's multiple interfaces.
VARIATIONS
A number of variations of this classification exist. Perhaps the most
common are nodes that provide a hybrid functionality betwen a Cx Node
and a BX Node. This is common in a young network such as ours as it is
more important to get some links in place than to do it in a strictlu
herachical sense.
BX CX HYBRID
A node that could qualify as a BX Node is more of well linked Cx
Node. This node has the typical Cient Nodes but also has a link (or
two) to other Bx Nodes on the same interface. The ideal situation
would be for this node to have a dedicated raido(s) for the links to
the Bx Nodes but for the time being the conncetion is established
using the omni interface of the node.
RE-TRANS
A re-trans is a pair of radios that provide linkage between two nodes
that would not otherwise be able to connect. A retrans may be
desirable due to terrain and the lack of suitable nodes in the
location.
HYPOTHETICAL EXAMPLE
In this example a number of Bx Nodes are configured in the same
manner. They use Ch 6 in IBBS mode to communicate to one or more Cx
Nodes that in turn use Ch12 in BSS mode to commuicate with a number of
Client Nodes. This is kind of an ideal situation, each Bx Node has 3
radios with dedicated links. In reality many of our Nodes will be less
optimal.
| +-----+IBBS +------+ | BxN [35] |---/--- -->|Client| +-----+Ch 6 /
+------+ IBBS|Ch 1 / +-----+IBSS +-----+BSS / +------+ | BxN [36]
|---/--->| CxN [37] |---/--->|Client| +-----+Ch 6 +-----+Ch12 +------+
| | +------+ This client could roam between the IBBS|Ch 11 -->|Client|
the two CxN [38] if they used the same ESSID | / +------+ | /
+-----+IBSS +-----+BSS / +------+ | BxN [39] |---/--->| CxN [40]
|---/--->|Client| +-----+Ch 6 +-----+Ch 1 +------+ IBBS|Ch 1
+-----+IBBS +------+ | BxN [41] |---/--- -->|Client| +-----+ +------+
|
LINK TYPES
It is possible to create a link in different ways, the commonest ways
are supported in most wireless devices (cards and APs). The simplest
links are those that use BSS mode where an AP is the hub for all
transmissions. This is fine for the Dx Node you use in the house and
for connecting Client Nodes to a Cx Node but has some limitations when
trying to use it for backbone links (the major one being that all
traffic is routed through the AP).
In the backbone it is useful to build redundancy through multiple
connections. Within a node this ideally would be through establishing
connections with multiple physical radios (i.e. a dedicated
transciever for each link) but cost and aavilability of other nodes to
connect to may not make this practical. The advantage of having
multiple connections is that as the density of nodes increases it is
possible that multiple nodes can provide alternative routes for
traffic.
ANTENNAS FOR LINKS
There is a limited set of choices here, somewhat dictated by the
protocol used for establishing the link.
omni ------/--- ---/--- omni ( hmmm, Ok, if you really have to...)
omni ------/--- >-------- directional ( Better, hybrid Bx Cx nodes do
this)
directional ----< >-------- directional ( Best!!)
PROTOCOLS FOR LINKS
There are four candidates for protocols that could be used for
establishing links. In reality while any protocol that is supported by
the devices at each end could be used some of tha available protocols
are not really the best for links ( as compared to supporting client
connection).
* BSS
* WDS
* Bridge
* IBBS
BSS
Using BSS for a backbone link can be done, on end runs as an AP while
the other runs as a BSS client. Each end would also has other links so
this is just a single circuit of the ones that are available. This is
a good choice for establishing a link in the initial instance and
while traffic is light. at the AP end the same radio could support
multiple links while at the client end there are a number of choices
of device that could be used.
Using this protocol the AP end is probably already correctly
configured for routing while the client end will need some further
configuration to work as a router rather than as a stand alone client
of the AP. The client may be an AP in client mode or a PC with a radio
card. Details of how to configure routing in a client device are on
the RoutingHowto [42] page.
Note: BSS is probably the most common protocol for AP-to-client
connection, the protocol being devised for this use. Using BSS for
establishing an inter-node (Bx-to-Bx or Bx-to-Cx) is a different use.
WDS
WDS is a higher level protocol that is used to support a roaming
environment for a Client. Multiple Nodes use the same ESSID and a
mobile client node is passed from Node to node based on signal
strength. WDS is a suitable protocol for the client Node cloud but
inappropriate for establishing the network backbone links.
BRIDGE
A bridge makes two physicly isolated network segments look like the
same segment. The bridging device at either end forewards traffic
across the bridge. This is a common use of WiFi [43] in a private
network. A bridge could be used to link two nodes but typically each
node would have it's own address range. The bridging device at one end
or another would have to act as a router or would have to feed into a
port on a router to allow each node to control it's own address space.
Bridge spanning two physical segments
192.168.1.0 +-----+ +-----+ 192.168.1.0 |================| |-< >-|
|==================| +-----+ +-----+ Bridge with additional router at
receiving end
192.168.1.0 +-----+ +-----+ 192.168.1.0 +-----+ 192.168.2.0
|================| |-< >-| |=============| |===============| +-----+
+-----+ +-----+
IBBS
IBBS is probably the best protocol to use to establish a link between
two nodes. It is a lower lvel protocol than BSS ( doesn't try to solve
the hidden node problem and routing decisions are promoted to layer 3
rather than being addressed at layer 2 see Layer2Assumptions).
192.168.1.0 +-----+ +-----+ 192.168.2.0 |================| |-< >-|
|===================| +-----+ +-----+
NODE EXAMPLES
Looking at the node finder we can see that there is not a lot of
linkage activity in our network yet. Some areas are well on the way to
creating isolated Bx Nodes that serve potential Cx Nodes but we don't
have much in the way of Bx Node linkage.
RGINNERNORTH
NodeBHH [44] is a great example of an almost-Bx Node. There are lots
of links sharing the same radio and some of these links are potential
Bx Nodes. This is an example of growing and changing as needed. If one
of the linked sites establishes a further link to another potential Bx
Node then BHH may drops it from the BSS connection and establshes a
dedicated link (or perhaps not!).
BSS|Ch 6 | +-----+BSS >| FUS |---/--- Bx----+Ch 3 +-----+BSS
+-----+BSS | BHH |---/--- >| FZJ |---/--- +-----+Ch 11 Cx----+Ch 3
+-----+BSS >| FMK |---/--- Cx----+Ch 8 +-----+? >| FNZ |---/---
Cx----+Ch ? +-----+ >| DCH | (ClientNode or Dx Node) +-----+ +-----+
>| HFL | (ClientNode?) +-----+
* NodeFZJ [45] is a Cx Node. It has a p2p link back to BHH and has an
omni for client connections.
* NodeFNZ [46] is another Cx Node with the backlink to NodeBHH [47]
* NodeDCH [48] looks like it has only one interface as either the
backlink to NodeBHH [49] (ClientNode). or acting as a Dx Node in omni
role.
* NodeHFL [50] looks like it has the backlink only, so is a Client
Node.
* NodeFMK [51] is a Cx Node with the uplink to NodeBHH [52].
* NodeFUS [53] is another Bx Node in waiting. It has 3 radios, on
connected p2p to BHH, another p2p (presumably waiting for someone to
connect it to - how about GPR?) and an omni for Cx Node or client
connections.
SOUTHERN
So whats going on here? NodeGMR [54] and NodeGES [55] are Bx Nodes
and AFH and FBD are on their way to being the same. Again the use of
BSS and linking into the omni of a neighboring node seems to be the
norm, the Bx Cx hybrid we saw in the other example.
+-----+ | HZN | +-----+ | | IBSS|Ch ? IBSS|Ch 2 | | +-----+BSS
+-----+BSS +-----+BSS +-----+BSS | GMR |---/--- >| GES |---/--- >| AFH
|---/--- >| FBD |---/--- Bx----+Ch 4 Bx----+Ch 1 Cx----+Ch 4 Cx----+Ch
1 | BSS|Ch ? | +-----+ >| GEZ | +-----+
DANDENONG FOOTHILLS
Classic Bx Node structure here.
BSS|Ch ? | +-----+BSS +-----+BSS +-----+BSS | AAF |---/--- >| GUR
|---/--- >| HKF |---/--- Cx----+Ch ? Bx----+Ch 8 Cx----+Ch 6 | |
+-----+ +-----+ | >| FGH | >| HUT | | +-----+ +-----+ | | +-----+
+-----+ | >| FUT | >| ICW | IBSS|Ch 6 +-----+ +-----+ | | +-----+
+-----+ | >| HCL | >| HNB | | +-----+ +-----+ | | +-----+ | >| GAZ | |
+-----+ | +-----+BSS +-----+BSS +-----+BSS +-----+ | FKR |---/--- >|
HKR |---/--- >| GWS |---/--- >| BFI | Bx----+Ch 1 Cx----+Ch 10
Bx----+Ch 11 +-----+ | | BSS|Ch ? +-----+ BSS|Ch 1 | >| HLR | |
+-----+ +-----+ >| HMF | +-----+ +-----+ >| FRJ | +-----+
IMPLEMENTATION OF A NODE
There are a number of ways to implement a node. All nodes fulfill the
same basic functions: provide a number of interfaces, provide
intelegent routing between interfaces and offer additional services.
+-----------------+ | | | | | +-----+ +------+ | | | | BSS | ---/---
to Cx Nodes or Client Nodes | | R | +------+ | | O | | | | U |
+------+ | | T | | IBSS | +++++++++ to peer Bx Node | | I | +------+ |
| N | | | | G | +------+ | | | | IBSS | +++++++++ to peer Bx Node | |
| +------+ | +-----+ | | | | SERVICES | | +-------------+ | | | DHCP |
| | | DNS | | | | HTTP | | | | FTP | | | +-------------+ | | |
+-----------------+
Implementations fall into one of two main types; Single box and
multiple box.
The Single box approach covers dedicated built-for-purpose devices
such as the WRAP computers, MIni-ITX based, Laptop based and includes
the re-used old PC.
The multiple box approach tends to be based on using multiple
domestic AP's and may have the routing function provided by either a
seperate box or by one of the AP's ( as is the case when using the
Linksys WRT54G ).
LINUX PC BASED NODE
This is relatively attractive as an old PC can be re-used and due to
the strong networking support in the Linux kernel can easily be
configured to perform the required routing. In this case routing is
managed in the box and the interfaces are PCI cards installed in the
same box.
The downside of a PC based node is the difficulty of finding a
suitable location for the PC - ideally you want to keep the cable runs
between the wireless cards and the antennas as short as possible but
the PC is quite large and dificult to place up a mast. Though it can
be done as in the case of NodeGES [56].
LAPTOP BASED NODE
In a similar fashon, an old laptop PC can be used as a node. In this
case the radios are most likely Cardbus (32 bit PCMCIA) with external
antennas. NodeBAE [57] is an example of this implementation.
DEDICATED APPLIANCE
A dedicated appliance such as a WRAP or net4801 is a small form
factor dedicated computer that supports multiple interfaces (either
Mini-PCI or Cardbus). These appliances can run stripped down versions
of Linux ( or other OS) and can boot from compact flash allowing a no
moving parts node to be created.
AP BASED NODE
An AP usually only has a single radio so in itself cannot fulfill all
the functions of a node (despite many AP's being able to provide
routing and other services). To build a higher function node more than
one AP is required. As well as multiple AP's there needs to be a
device providing routing between the AP's and any wired segments in
the node. The use of a hackable AP like the WRT54G allows the routing
function to be combined with or of the radio interfaces reducing the
number of boxes required.
MULTI-BAND AP
A multi band AP could be used to implement a Cx Node if the other end
of the link( to the BX Node ) supports 802.11a. AN example of this
would be the DLink DLW-7100AP [58]
IMPLEMENTATION PRICING COMPARISON
< Not done yet, though there may not be all that much difference
between implemetations when all components are considered. >
OTHER CONSIDERATIONS
AP BRIDGING VS. ROUTING
One problem with AP's in general is that they are normally a bridged
device. This means that they bridge between the wired and wireless
interfaces and because of this extend the network segment they are
connected to rather than provide a route to it.
An example probably makes this clearer.
Node A is a Linux PC (as in the above section). It is connected to an
internal ethernet segment 192.168.10.0 via eth0.
It has three wireless interfaces:
* eth1 10.10.1.64/28 running in IBBS AP mode into a waveguide antenna
* eth2 192.168.11.1 running IBBS mode into a grid antenna connected
to node B
* eth3 192.168.12.20 from DHCP running in BSS client mode connected
to node C
Node A has IP forwarding configured and runs an OSPF daemon. It had
static links configured for the links to node B and node C.
Node D has an AP running in client mode and establishes a link to the
BSS service on the eth1 interface of node A. Node D gets an IP address
from node A via DHCP and huh? the IP address of the wired interface of
node D is also the same as the wireless one. What's happened here?
Unlike a PC interface there is no way to get into the AP and
configure it to have different IP addresses on the two interfaces. The
AP is configured at the factory to bridge the two interfaces rather
than route between them.
What we were hoping to get:
Node A Node D 192.168.1.0 +-----+ BSS +-----+ 192.168.2.0
--------------| | ---/--- >---| |------------ +-----+ +-----+
What we got:
192.168.1.0 +-----+ +-----+ 192.168.1.0 --------------| | ---/---
>---| |------------ +-----+ +-----+
Node D is bridging the two wired lan segments.
Some AP's are able to be configured to run in multiple modes:
* As an AP
* In IBBS mode
* As an AP (BSS) client
* As part of a WDS cloud
When using multiple AP's in combination with a router controled
switch you can use the vlan capabilities of the switch to take
advantage of the bridged nature of an AP. In this way despite the AP
bridging the switch can be configured to perform routing from the port
connected to the AP.
PUBLIC SEGMENT
I am using the notion of a public segment between multiple devices
that forms part of the network. The reason for this was to remove the
dependancy on the (precious) 10.10.0.0/28 subnet for the internal
parts of the node and to get the most flexability on the internal
implementation.
Each of the three uplinks can run as either an IBBS peer to the other
end of the link or as a BSS client(in which case they take one of the
subnet addresses from the AP at the other end. It really depends on
the nature of the link - dedicated radios at each end would use IBBS
mode and could use any subnet to communicate.
P2P dedicated P2P dedicates Client of a P2MP server link link P2MP
server interface
192.168.51.0 192.168.50.0 10.10.x.x/28 10.10.1.64/28 | | | | |2 |2
|(DHCP) |65 +-------+ +-------+ +-------+ +-------+ | IBBS | | IBBS |
| BSS | | BSS | +-------+ +-------+ +-------+ +-------+ |4 |3 |2 |1 |
| | |
|--------+--------------+--------------+--------------+---------|
192.168.100.0
USING VLANS ON YOUR WRT54G
If you have a WRT54G youto use cheap off the shelf AP's (like the
Minitar) as a link interfce. Typiclly the AP will be either a client
of the other end of the link (in BSS mode) or part of a P2P link in
IBBS mode. The AP will bridge between the wired and wireless and
"extend" the address space of the remote end of the link. This as
coverd before is not really a good thing but in this case the AP can
be addressed as a dedicated VLAN in the WRT54G for the cost of an
additional address in the link or remote end space.
Links:
------
[1] http://melbournewireless.org.au/#introduction
[2] http://melbournewireless.org.au/#logical_view_of_different_nodes_
[3] http://melbournewireless.org.au/#client_nodes
[4] http://melbournewireless.org.au/#dx_node
[5] http://melbournewireless.org.au/#cx_node
[6] http://melbournewireless.org.au/#bx_node
[7] http://melbournewireless.org.au/#ax_node
[8] http://melbournewireless.org.au/#variations
[9] http://melbournewireless.org.au/#bx_cx_hybrid
[10] http://melbournewireless.org.au/#re_trans
[11] http://melbournewireless.org.au/#hypothetical_example
[12] http://melbournewireless.org.au/#link_types
[13] http://melbournewireless.org.au/#antennas_for_links
[14] http://melbournewireless.org.au/#protocols_for_links
[15] http://melbournewireless.org.au/#bss
[16] http://melbournewireless.org.au/#wds
[17] http://melbournewireless.org.au/#bridge
[18] http://melbournewireless.org.au/#ibbs
[19] http://melbournewireless.org.au/#node_examples
[20] http://melbournewireless.org.au/#rginnernorth
[21] http://melbournewireless.org.au/#southern
[22] http://melbournewireless.org.au/#dandenong_foothills
[23] http://melbournewireless.org.au/#implementation_of_a_node
[24] http://melbournewireless.org.au/#linux_pc_based_node
[25] http://melbournewireless.org.au/#laptop_based_node
[26] http://melbournewireless.org.au/#dedicated_appliance
[27] http://melbournewireless.org.au/#ap_based_node
[28] http://melbournewireless.org.au/#multi_band_ap
[29]
http://melbournewireless.org.au/#implementation_pricing_comparison
[30] http://melbournewireless.org.au/#other_considerations
[31] http://melbournewireless.org.au/#ap_bridging_vs__routing
[32] http://melbournewireless.org.au/#public_segment
[33] http://melbournewireless.org.au/#using_vlans_on_your_wrt54g
[34] http://melbournewireless.org.au/?CxNode
[35] http://melbournewireless.org.au/?BxN
[36] http://melbournewireless.org.au/?BxN
[37] http://melbournewireless.org.au/?CxN
[38] http://melbournewireless.org.au/?CxN
[39] http://melbournewireless.org.au/?BxN
[40] http://melbournewireless.org.au/?CxN
[41] http://melbournewireless.org.au/?BxN
[42] http://melbournewireless.org.au/?RoutingHowto
[43] http://melbournewireless.org.au/?WiFi
[44] http://melbournewireless.org.au/?NodeBHH
[45] http://melbournewireless.org.au/?NodeFZJ
[46] http://melbournewireless.org.au/?NodeFNZ
[47] http://melbournewireless.org.au/?NodeBHH
[48] http://melbournewireless.org.au/?NodeDCH
[49] http://melbournewireless.org.au/?NodeBHH
[50] http://melbournewireless.org.au/?NodeHFL
[51] http://melbournewireless.org.au/?NodeFMK
[52] http://melbournewireless.org.au/?NodeBHH
[53] http://melbournewireless.org.au/?NodeFUS
[54] http://melbournewireless.org.au/?NodeGMR
[55] http://melbournewireless.org.au/?NodeGES
[56] http://melbournewireless.org.au/?NodeGES
[57] http://melbournewireless.org.au/?NodeBAE
[58]
http://www.dlink.com/products/resource.asp?pid=304&rid=1016&sec=0
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]
Node Statistics | |
---|---|
building | 132 |
gathering | 193 |
interested | 515 |
operational | 233 |
testing | 214 |