Re: [rrg] TARA and voluntary adoption

[[e-mail]]

 
Hello Robin,
 
Below I have inserted the text of a preceding email you might have read  
already.  
The hereby proposed location identifiers (or tokens, or names, or  
attributes) are aggregatable like no other scheme and can indeed be used to  develop 
a routing architecture which aggregates the internet topology such that  it 
contains parts thereof the more reduced (sparsed) the more  remote they  
are.
 

I haven't received any on-list response so far. Since Bill Herrin brought  
up the commercial relation argument people are convinced that restrictions 
due  to business relations of the ISPs can only be communicated implicitly 
(i.e. by  distance vector technique) and cannot be  communicated explicitly. 
Because I think that can be done for sure, I  think that can be considered 
later, i.e. is not a non-starter argument at  all. 
 
 
Instead, routing technology should be addressed in the first  place.E.g. 
Hierarchical routing.
I could imagine that the term hierarchical routing excites every one. But I 
 needs to be done properly.
I have my doubts that both hierarchical routing as well as geo-location  
based routing have ever been discussed adequately. Stretch is not the only bad 
 aspect of all the "well-known" and in my opinion wrong hierarchical 
models. I  also presented the Istanbul-argument which shows how important a 
"SLIDING  hierarchy" is.
Allegeably "we are thru the geo-location options". Has there anyone ever  
discussed the difference between a big sized flat network and a big sized  
network which shapes a globe ?
 
Heiner 
 
 
 
 
 
 
 
 
---------------------------------------------------------------------------    
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).
 

 
 
In einer eMail vom 03.12.2009 03:19:28 Westeuropäische Normalzeit schreibt  
[e-mail]:

Hello  Heiner,

None of what you wrote in this message or any other message you  have
written to the RRG (260 in total since April 2007) provides even  a
fraction of what is required to understand your TARA proposal.

I  suggest you write a proper document describing *exactly* how it
works, with  bits, bytes, routers, protocol details etc. and then
announce this document  on the RRG list.  You frequently try to
describe TARA by analogies to  things other than Internet routing, but
these do not help me - or I guess  anyone else - understand your
proposal.

Only once you have published  a comprehensive description of TARA will
I discuss it  further.

- Robin