* [#introduction Introduction] * [#logical_view_of_different_nodes_ Logical view of different nodes:] ** [#client_nodes Client Nodes] ** [#dx_node Dx Node] ** [#cx_node Cx Node] ** [#bx_node Bx Node] ** [#ax_node Ax Node] ** [#variations Variations] *** [#bx_cx_hybrid Bx Cx Hybrid] *** [#re_trans Re-trans] * [#hypothetical_example Hypothetical example] * [#link_types Link types] ** [#antennas_for_links Antennas for links] ** [#protocols_for_links Protocols for links] *** [#bss BSS] *** [#wds WDS] *** [#bridge Bridge] *** [#ibbs IBBS] * [#node_examples Node Examples] ** [#rginnernorth RGInnerNorth] ** [#southern Southern] ** [#dandenong_foothills Dandenong Foothills] * [#implementation_of_a_node Implementation of a Node] ! 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 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 |---\/\--- -->|Client| +-----+Ch 6 / +------+ IBBS|Ch 1 / +-----+IBSS +-----+BSS / +------+ | BxN |---\/\--->| CxN |---\/\--->|Client| +-----+Ch 6 +-----+Ch12\ +------+ | \ | \ +------+ This client could roam between the IBBS|Ch 11 -->|Client| the two CxN if they used the same ESSID | / +------+ | / +-----+IBSS +-----+BSS / +------+ | BxN |---\/\--->| CxN |---\/\--->|Client| +-----+Ch 6 +-----+Ch 1\ +------+ IBBS|Ch 1 \ +-----+IBBS \ +------+ | BxN |---\/\--- -->|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 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 in a private network. A bridge could be used to lonk 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 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 DxNode) +-----+ +-----+ >| HFL | (ClientNode?) +-----+ * NodeFZJ is a Cx Node. It has a p2p link back to BHH and has an omni for client connections. * NodeFNZ is another Cx Node with the backlink to NodeBHH * NodeDCH looks like it has only one interface as either the backlink to NodeBHH (ClientNode). or acting as a Dx Node in omni role. * NodeHFL looks like it has the backlink only, so is a Client Node. * NodeFMK is a Cx Node with the uplink to NodeBHH. * NodeFUS 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 and NodeGES 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 (regardless of type). Regardless of implemetation they fulfill the same basic function, provide a number of interfaces, provide intelegent routing between interfaces and offer additional services. << I'll finish this later - dna >>