Subject: Re: [rrg] Constraints due to the need for widespread voluntary adoption

From: [email-masked]
Date: Tue, 1 Dec 2009 06:43:34 EST

In einer eMail vom 01.12.2009 11:54:32 Westeuropäische Normalzeit schreibt  
[email-masked]:

On Tue,  Dec 1, 2009 at 11:42 AM,  <[email-masked]> wrote:
>  Your (and other's) future routing architecture depends heavily on the
>  continued existence of non-IP / telephone network architecture. You  
mention
> millions (billions ?) of mobile handsets and are afraid of  their 
prefixes.
> All I hear is mapping, mapping, mapping: enum-mapping,  RLOC-mapping...
>
Heiner,

I have taken another approach, going  after the flat address structure
and introducing a hierarchy level on top  of the old one. No mapping is
needed.
Well, a routable namespace (as is used by TARA) could be the base for even  
time-of-day routing.
Look, TV-multicast with millions of receivers e.g. multicasting a soccer  
final for 90 minutes would bring immense traffic load, which needs to be  
well-balanced.
 
Today in Sueddeutsche Zeitung an article about smart grid powerline network 
 mentions that Cisco sees a 100 times bigger network here to come compared 
with  the internet. But so far, the reaction wrt TARA's abolishing the  
scalability problem even if it were 1000 times bigger was that the task is  only 
to reduce the problem.

Patte wrote: 
And I share your concern about having a mapping  database for routing
information - guess it would be the main target in a  cyberwar
situation, either by hacking it or change the legislation in a  wartime
situation to take control of the database (?) - the question is, is  it
possible for one nation to take down another nation's  Internet
infrastructure by getting access to the mapping database??
Note!  This is an open question since I haven't studied the mapping
solutions in  detail

-- patte

Yes,  LISP's distributed database is either no reduction of the  routing 
churn (if too broad) and otherwise a huge polticial problem - both  in case of 
a cyberwar attack as well as due to the potential threat as to  decline 
service. The EU's Galileo initiative is not because GPS isn't good  enough but 
because its service  could be denied by the political  owner.
Imho, this is the most severe non-starter argument. Thank you for  sharing 
this concern.
 
Heiner

---

From: [email-masked]
Date: Fri, 4 Dec 2009 13:48:11 EST

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

---

From: "sunletong" <[email-masked]>
Date: Tue, 08 Dec 2009 17:56:37 +0800

Hi Robin:

I read your implementation constraints document (on http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/) a few days ago and rethink my proposal of layered mapping system. The system's main idea is to have a neutral or another interest group orthogonal to ISPs maintaining a mapping system, and charge for mapping services (like CPs), based on the separation scheme.  Mapping nodes are organized hierarchically and maintains pointers to their children to guarantee scalability. I think the idea basically meet with the constraints you mentioned, and i also came up with a thought of an intermediate way to reduce routing table size and establish the mapping system in today's situation where no separation between core and edge address is taken. The goal is to show that a mapping system can be constructed incrementally through economical incentives and also to pave roads for the final core-and-edge-address separation. At the time the two namespaces separate, the having constructed mapping system and related core routers would only have to update their data plane in their database without their main functions being changed. To see the mapping system design please refer to the "A layered mapping system", and the intermediate solution is in "How to implement a mapping system".

Following is a few response to your proposed constraints:

1 - The solution must provide immediate and
compelling benefits to any new or existing
end-user networks which adopt it, irrespective
of how many other networks have so far adopted
it.

Any ISP router who discards the edge address routing and ask mapping system could benefit instantly with their routing table shrinked. Besides, the request charge would be much less than an upgrade of a router. A well-organized mapping system  and well-designed cache in the ITR would significantly reduce or remove the additional requesting delay.

2 - Therefore, it must provide multihoming, TE and
portability for the adopting networks in a
manner which fully supports communications with
all hosts - including all hosts in non-upgraded
networks.

Basically there's no change in the edge network so all hosts can communicate just as what they do today. Besides,

Multihomed edge networks would inform mapping servers of their multiple upstream routers. With different priority attributes being set, they can control their incoming flows which is hard to achieve today.

3 - Therefore, the solution must be compatible with
all hosts (stacks and applications) and routers
in non-upgraded networks.

Same as 2.

4 - The solution must be compatible with all
existing applications in the adopting networks.

Since the changes are mainly made in the core and add additional services, I didn't see any harm to existing applications.

5 - Although in principle, some or many host stacks
could be upgraded in the adopting networks, the
difficulties this presents means that a scalable
routing solution will only be widely enough
adopted on a voluntary basis if no such upgrades
are required in order for the new system to
provide compelling benefits.

The mapping mechanism is transparent to customers and they use edge network address to do what they today are doing.

Firstly, there are difficulties in motivating
operating system / stack programmers to add and
test new facilities.  Secondly there may be
costs and disruption for the adopting network in
upgrading the stacks.  Thirdly, in many or most
end-user networks, some or many hosts will not
be amenable to stack upgrades due to them using
operating systems which are no longer being
maintained or developed.  This is especially
the case for devices such as printers, routers
etc. which do not use one of the major
operating systems.

6 - If the solution requires extra functionality in         * 04
interdomain routers, then it must be feasible from      *
technical and business perspectives for the relevant    *
routers to have this functionality in time for          *
deployment.  For instance, a core-edge separation       *
scheme which relied on new router functions for         *
ITR to ETR tunneling would require the functionality    *
to be present in all transit routers and in the         *
routers of all ISPs with customers which adopt the      *
solution.                                               *

The separation scheme needs core routers to enable tunnelling, well it is easy to upgrade and ISP routers need to do this for the accessibility of their customers. Since when a source transit router requests the mapping system and forms an encapsulated packet to a destination router, if the destination cannot de-encapulate the packet, it just drops it. This means its customers are isolated as to the upgraded ISPs and their customers.

7 - The solution must be attractive for the large
number of smaller networks who currently cannot
get PI space to do multihoming etc.  Our goal is
not just to reduce the number of DFZ routes but
to enable a much larger number of end-user
networks to gain multihoming, TE and portability
than is currently possible.

Multihomed edge networks can indeed benefit much from the mapping system, e.g. to control their incoming flows.

8 - Ideally the solution will also be attractive for
most or all end-user networks who currently have
their own PI prefixes.  This is firstly to
improve scaling by attracting those larger
end-user networks away from their current
conventional PI address space usage and secondly
to ensure that smaller networks which aspire to
be bigger in the future will perceive the new
kind of scalable end-user network address space
as suitable for their long-term needs.

PI-users can just stay where they are, or I thought they just become ordinary multihomed users as those using PA.

9 - Ideally the new system should not compromise
security or performance compared to that of
current PI or PA techniques.  Any degradation in
security, packet path lengths, end-to-end packet
transit times, packet loss rates and general
robustness etc. needs to be more than
compensated for by reduced costs and/or benefits
such as a more flexible and responsive
multihoming restoration capability than is
possible with current BGP techniques.

Very good point. The benefits of routing table shrinking and multihoming etc. are gained at the cost of request time for mapping, which in turn causes large transit times or packet drops. Well we can carefully design the structure of the mapping system and place well-performed cache in transit routers to reduce the response time a request may experience. You doubt the generality of experiment result of Florin's www.ietf.org/proceedings/75/slides/lisp-4.pdf), while the locality property of destination addresses have discovered in many studies (e.g. Florin's, [1][2] and ours :)), and we can borrow lessons from the success of caches used in the DNS.

10 - The solution will probably not be widely enough
adopted if it requires upgrades to the internal
routers of adopting networks - except perhaps in
small networks such as SOHO where one or a few
inexpensive routers need upgrading anyway to
perform ITR and ETR etc. functions.

I don't quite understand your meanings here, but perhaps you refer to the case when ITR and ETR are at the edge networks? Our intention is to place them in the core.

Could you and anyone else be kind enough to give me comments on our thoughts? Any criticism on my innocence is warmly appreciated: )

Letong

[1]On the Cost of Caching Locator/ID Mappings, Luigi Iannone.

[2]Revisiting Route Caching: The World Should Be Flat, Changhoon Kim