home 
wiki
wiki
Spelling: OSPFArchitecture
* So how does it work?! [1]
* Regular Nodes [2]
* none [3]
* Routing Nodes [4]
* internal area router [5]
* area border router [6]
* system border routers [7]
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 [8] 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 address allocation
[9]. As a result these addresses are used as an example.
HELP: If, after reading this page you need some help with your OSPF
[10] setup, check out Help [11]
SO HOW DOES IT WORK?!
Melbourne has been divided up into - initially - 11 geographic areas.
[12] 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 LOS [13] to a neighbouring area - in which case choose the area
you have better LOS [14] 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 [15] 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 [16] 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 [17]. 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 [18] 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.
Links:
------
[1] http://melbournewireless.org.au/#so_how_does_it_work__
[2] http://melbournewireless.org.au/#regular_nodes
[3] http://melbournewireless.org.au/#none
[4] http://melbournewireless.org.au/#routing_nodes
[5] http://melbournewireless.org.au/#internal_area_router
[6] http://melbournewireless.org.au/#area_border_router
[7] http://melbournewireless.org.au/#system_border_routers
[8] http://melbournewireless.org.au/?WGRoutingAddressing
[9] http://melbournewireless.org.au/?AddressAllocation
[10] http://melbournewireless.org.au/?OSPF
[11] http://melbournewireless.org.au/?OSPF
[12] http://melbournewireless.org.au/?RegionalGroups
[13] http://melbournewireless.org.au/?LineOfSight
[14] http://melbournewireless.org.au/?LineOfSight
[15] http://melbournewireless.org.au/?OSPF
[16] http://melbournewireless.org.au/?Bandwidth
[17] http://melbournewireless.org.au/?MelbWireless
[18] http://melbournewireless.org.au/?MelbWireless
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]