Experimental RFC 1712 introduces the use of geographical coordinates which I recommend to exploit for creating globally unique locators as follows: According to the longitudes and latitudes there are 64800 geo-patches (= spheric triangles at the poles, = spheric squares otherwise). Each of them can be indexed by 2 octets if we number them as follows. We start with number 1 for that triangle at the south pole which is east of the Greenwhich- 0° longitude and continue numbering while going eastward (only) such that the triangle adjacent to geo-patch #1 gets number 360. Then we continue with the nex upper row in the same way, and so on until we have numbered all geopatches including those of the uppest row around the north pole. A mapping function as to map the well-known coordinates with their east/west of Greenwich and north/south of equator specialities onto some geo-patch index can easily be built. Furthermore each geopatch can be understood as 60 x 60 =3600 square minutes. Each such square minute patch can be indexed by a number between 1 and 3600 (12 bits) in a very similar way (always going east to make up a particular row, one row after the other closer and closer to the north pole). Analoguously square seconds could be numbered but for reasons of memory savings, we shouldn't do that. Instead, longitude second# (between 1 and 60 requiring 6 bits) and latitude second# (between 1 and 60 requiring 6 bits) should be formed such that we comply with the east- resp. north bound direction (in the western hemisphere the longitude-second becomes 60 minus the respective classic value, so does the latidude-second south from the equator). Hence any packet should have a header which contains (both for source and destination) the 4 information: 1) square degree geo-patch# (1 - 64800) , 2) square minute # (1-3600), 3) longitude second#, 4) latitude second#. A router which receives a packet shall ask: Does my own square degree index (=x) match that one as is indicated in the packet wrt the receiver (=y)? If not, It may offset a table by y and retrieve the next hop. Otherwise information 2), 3) and 4) shall be used to retrieve (by means of altogether 3 lookups in 3 further tables) the next hop. Conclusion: Moore's law will become applicable (and caching isn't required either). Should,temporarily, some other than the best next hop be the appropriate next hop, then for the time being that other next hop information shall be placed at the table position of the best next hop. The point however is, how can we fill the 4 lookup-tables with the proper next hop data. This would be the major task of TARA. Let me add: the derived geo-location data wrt to the receiver denote the location of that router at which forwarding in the described way shall end ( i.e. from where on the IP-address shall be used to determine the next hop resp. the delivery to the user). Heiner
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
