home 
wiki
wiki
Spelling: IPAllocation
* IP address space must be controlled for the following reasons [1]
* To allocate in a way that satisfies these demands requires [2]
* So what are the \'needs of requestor\'? [3]
* What information do we need on the requestor? [4]
* How do we allocate in order to support the routing architecture?
[5]
IP ADDRESS SPACE MUST BE CONTROLLED FOR THE FOLLOWING REASONS
* it is a limited resource
* controlled allocation required to allow for routing scalability
* administrative control needed to allow interconnection /
uniqueness
TO ALLOCATE IN A WAY THAT SATISFIES THESE DEMANDS REQUIRES
* consideration of needs of requestor
* web based entry, eyeballs to assess?
* a system to record allocations
* database, backed up, identity of requestor, linked to node map?
* allocation based on location in topology
* as described in routing architecture
SO WHAT ARE THE \'NEEDS OF REQUESTOR\'?
* how many wide area wireless interfaces in routing nodes (as defined
in address allocation [6]) - now, and anticipated. This converts into
the allocated and reserved number of IP addresses in backbone address
range.
* how many clients do they expect to have (now and in future)
* connected on their site
* on other sites via subtended wireless to nodes that are not wide
area routing nodes
WHAT INFORMATION DO WE NEED ON THE REQUESTOR?
* node map identifier (e.g. CIA)
* verification password
* do we trust that drew has the rest?
* Drew: yes, we could even use the same password, and/or store this
info in the current db
* an acknowledgement of the terms upon which addresses are assigned,
e.g.
* the assignment may be withdrawn
* that they agree to configure systems within the bounds of the
assignments in order to interoperate with other melbourne wireless
nodes
HOW DO WE ALLOCATE IN ORDER TO SUPPORT THE ROUTING ARCHITECTURE?
* need a way of allocating backbone IP to begin with
* the 512 addresses in 172.16.80.0/23
* There are 85 'going' nodes as of 20/5/02
* The intent is that growth of nodes in the backbone is slowed, as
new nodes are diverted into areas hanging off the backbone. If the
backbone grows larger than 512 nodes OSPF will struggle anyway, we
would need to split the backbones and have them peer with each other
via BGP or the like.
* We will put all these in the backbone to begin
* Divide the area of metro into 16 regions of similar number of
nodes
* this is 32 addresses form backbone for each region
* should we use electorates?!!
Links:
------
[1]
http://melbournewireless.org.au/#ip_address_space_must_be_controlled_for_the_following_reasons
[2]
http://melbournewireless.org.au/#to_allocate_in_a_way_that_satisfies_these_demands_requires
[3]
http://melbournewireless.org.au/#so_what_are_theneeds_of_requestor
[4]
http://melbournewireless.org.au/#what_information_do_we_need_on_the_requestor_
[5]
http://melbournewireless.org.au/#how_do_we_allocate_in_order_to_support_the_routing_architecture_
[6] http://melbournewireless.org.au/?AddressAllocation
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]