home 
wiki
wiki
Spelling: architecture
This work overlaps with that of the RFC [1], but approaches from a
different angle.
SCOPE
This document specifies an architecture to support a community
Internet Protocol network that heavily utilises IEEE 802.11 Wireless
LAN technology for connectivity.
REQUIREMENTS.
Connectivity: need to provide IP connectivity between sparsely
scattered nodes to begin with. Later deal with higher levels of
density. Support subnets behind attached clients and single host
clients. Manage network resources in a 'fair' manner that recognises
the investment by infrastructure owners. Support end-to-end security
of selected communications across the network.
Scalability: engineer to support ~ 1000 node. Clear evolution paths
to higher number of nodes.
Performance: provide efficient use of radio resources, shared in a
'fair' manner that is not open to abuse.
Utilise wireless LAN commodity hardware and homebrew antenna to
provide infrastructure.
Support ruggedised low cost nodes capable of outside mounting and
feasibly shared to assist in line of sight connectivity in sparse
environs.
Support higher capability nodes (that might for instance be found
within a house) mixed with low cost nodes.
IP NETWORKING TECHNOLOGIES.
* IPsec, CIPE
* IPv4/IPv6 mix
* OSPF?
* Diffserv
* Secure DNS
ISSUES
* Addressing
* Resilience to DDoS
* Security
* Connectivity without requiring too many interfaces at a node.
* Channel plans
* Antenna configuration
* Routing
OUTLINE
Seattle wireless has the concept of (A|B|C)xNodes This is perhaps
required for a longer term network architecture, but the requirements
make it difficult to build minimum expense access points that can link
to the grid initially. The concept described here attempts to present
a peer-to-peer architecture with no initial levels of hierarchy.
THE MINIMAL NODE
The basic node consists of a Linux router with either an 802.11 AP
connected via an ethernet or a directly attached 802.11 interface.
This node has two functions
* to connect to the Melbourne Wireless WAN
* to offer connectivity to local nodes
* that might be wired
* or wireless
The complicating factor with a minimum node is that we attempt to use
the same wireless interface to provide support for both local wireless
clients, and connecting to distant Melbourne Wireless nodes.
WIRELESS INTERFACE MODE OF OPERATION
Two choices: we can run it in IBSS or BSS mode. If we run in IBSS
mode
* can connect to remote instances of this same type of node
* local clients must also run in IBSS mode
* cannot really support a normal access point on the end of an
ethernet - although the OpenAP [2] is a different matter.
If it is run in BSS mode
* cannot connect to remote instances of this type of node in an
ad-hoc fashion; instead the node most be configured to 'bridge' to
other nodes on a node-by-node basis (if it is even possible
* local clients can run in the normal BSS mode as found in normal
enterprise installations of wireless LAN (less fuss in configuring
wireless clients)
* can support access points on the end of an ethernet connected to
the router box
TO BE CONTINUED..
* Using whois as a network information repository like APNIC et. al.
* Benefit of (globally unique) IPv6 based services when
interconnecting community WANs with NAT and Internet wormholes
* Benefit of IPv6 A6 chain records for hierarchical reverse DNS and
renumbering
* Conversely the problem of allocating out /28s and inverse DNS
delegation
Links:
------
[1] http://melbournewireless.org.au/?RFC
[2] http://melbournewireless.org.au/?OpenAP
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]