** [#so_how_does_it_work__ So how does it work?!] ** [#regular_nodes Regular Nodes] *** [#none none] ** [#routing_nodes Routing Nodes] *** [#internal_area_router internal area router] *** [#area_border_router area border router] *** [#system_border_routers system border routers] Whilst the Melbourne Wireless network is in it's current form - small clusters of connected computers - city wide routing isn't really a problem. It's fine to just use static routes, and add/remove them as needed. However, as soon as these clusters start to link (which will be happening soon), we're going to start running into problems. Nodes will go up and down, routes will change, and connecting over any distance will be impossible. For this reason, the [WGRoutingAddressing] working group has looked at a bunch of routing protocols to find which one suits our needs best, and OSPFv2 has come out as the best of a bad lot. I say bad lot, since there really isn't any ''mesh'' routing protocol that is mature, stable, and scalable to a city size, so the remaining options are designed for a network as complex as ours will be. OSPF was chosen as it has the following key attributes: * supports CIDR * efficient routing information distribution * link state based protocol does not suffer problems like distance vector based * features such as areas allow for hierarchy within the IGP '''Note:''' Melbourne Wireless has reserved the IP address ranges 172.16.80.0/20 and 10.10.0.0/16 as described in [AddressAllocation address allocation]. As a result these addresses are used as an example. '''HELP:''' If, after reading this page you need some help with your [OSPF] setup, check out [OSPF Help] !! So how does it work?! Melbourne has been divided up into - initially - [RegionalGroups 11 geographic areas.] We have left ip space to create more areas in the future if need be. To join the network, every node must choose a region to place themselves in. This isn't as simple as where you are on the map, as it's based on netwrok conectivity. Obviously this will be roughly geographic (since nodes near each other will connect to eachother), but you may find that geographically your in one area, but you have better [LineOfSight LOS] to a neighbouring area - in which case choose the area you have better [LineOfSight LOS] to. As well as choosing an Area, each node must decide what OSPF mode it is going to run in. This is where things start to get a bti complicated! So straight away, your either not running OSPF (a ''regular'' node), or you are (a ''routing'' node) !! Regular Nodes !!! none The most basic [OSPF] mode, is ''none''. Initially, we expect most nodes will fit this mode. Quite obviously, this means your not running OSPF (either because you don't know how, or don't need to, or whatever). Routes for these nodes will be static, so they will probably have 1 connection upstream, and the node they're connected to will be their default route. The upstream node is then responsible for handling how your traffic gets to where its supposed to go, and you don't really care how that happens. There could conceivably be a chain of nodes, all with default routes upstream to a single node that then runs OSPF, and this would work fine. As long as everyone down the chain sets their defult route upstream, and all traffic eventually reaches the node running OSPF. Like all nodes, this node is entitled to a block of 16 ip addresses from 10.10.x.x, to be used how they see fit. !! Routing Nodes !!! internal area router An ''internal area server'' is a server that routes traffic around the inside of an area. (der..) It would more than likely have at least 2-3 p2p links with other internal area routers, and most importantly, ''it tells each of its neighbouring routers what ip addresses it can see''. This happens on a fairly regular basis, so if someone driving by happens to connect, or a new node goes operational, they will be able to connect to and from distant nodes. Besides is allotment of 16 10.10.x.x addresses, this node type, as well as the other routing nodes, will be assigned _1_ address from 172.16.80/20 for each p2p interface that links to another routing node. !!! area border router Ok. So if i try to connect to another node in Area 4, the ''interal area routers'' will handle it and make sure my data gets to where its going - but what about if i want to connect to somebody in a different area? ''Area border routers'' are very similar to internal routers, but they bridge 2 or more areas. They know that all IPs from a given area fall into a certain range, and will redirect the traffic accordingly. Again, like ''internal area routers'', they get their own 10.10.x.x block, and a single address from 172.16.80/20 for interfaces that link to other routing nodes. Importantly, although ''area border routers'' are located in an area, and all their interfaces that link to ''internal area routers'' area use that area, an interface that links '''to another area border router''', be it another ''area border router'' inside the home area, or in another area, are assigned '''area 0'''. These links are referred to as '''backbone''' links. Anytime your data has to travel across several areas, once it enters the backbone from an area border router in your area, it must stay on it until it gets to the destination area. For this reason, the backbone links need to be as fat and reliable as possible - see [Bandwidth] for more discussion on this issue !!! system border routers these aren't all that different to ''area border routers'', except that they link to networks that aren't a part of MelbWireless. For example, another Community Wireless group, or whatever. (providing the address space doesnt clash with ours). The routes to these other networks can be discovered via any protocol, and are then boradcast onto the MelbWireless network using OSPF. Addressing is the same as for ''area border routers'', and the same rules apply for classing links as backbones. Any interface that links to another system border router or an ''area border router'' is classed as a backbone, and is a part of Area 0.