home 
wiki
wiki
architecture
This work overlaps with that of the RFC, 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
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 is a different matter.
- 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
Version 1 (current) modified Mon, 26 Jul 2021 12:49:29 +0000
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]