Routing Research Group Heiner Hummel Internet Draft Intended status: Informational September 19, 2010 Expires: March,22 2011 Topology Aggregating Routing Architecture draft-hummel-tara-00.txt Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hummel Expires March 20, 2011 [Page 1] Internet-Draft TARA September 2010 Abstract This draft outlines a new routing architecture which I like to call TARA = Topology Aggregating Routing Architecture. Its primary objective is to eliminate the so-called scalability problem as proclaimed by RFC4984. By overcoming the true causes of this problem - which are indeed some holy routing paradigms - it may serve as the base for much better routing. 1.Introduction and motivation This draft outlines a new routing architecture which I like to call TARA = Topology Aggregating Routing Architecture. Its primary objective is to eliminate the so-called scalability problem as proclaimed by RFC4984. By overcoming the true causes of this problem - which are indeed some holy routing paradigms - it may serve as the base for much better routing. Just one single example: ECMP is by far not the end of better routing. In many cases routing via some more distant node is the only existing alternative to some single shortest path. However by sticking to Distance Vector inter- domain forwarding will never ever enable such alternatives. TARA will abolish the crazily excessive RIB/FIB memory consumption! Today, a BGP-router collects millions of downstream paths and yet is unable to see and utilize any upstream path - neither for forwarding (detour), nor for traffic load handling. TARA will abolish the crazily excessive UPDATE-churn! The hereby consumed CPU-performance may better be used for well concerted and well scoped traffic load notification messages. TARA will make Moore's law become applicable: Next-hop selection will be done by either one or three indexed table element lookups. No FIB binary search and no caching is needed. Furthermore, the IPv4 address depletion will become a non-issue, because global uniqueness of the IPv4 address won't be required anymore. Because the destination's IP address is not evaluated prior having reached the TARA-ETR, its uniqueness is just required within the local scope between TARA-ETR and egress router. Hummel Expires March 20, 2011 [Page 2] Internet-Draft TARA September 2010 TARA will transform the internet topology agnostic BGP to become an internet topology aware BGP ! It will transform the Distance-Vector- based BGP to become a Dijkstra-(and Beyond-Dijkstra- ) based BGP! By means of BGP UPDATE extensions several (e.g. 5) differently zoomed i.e. differently skimmed topologies of the entire internet will be "produced". It will be done in such a way that no single TARA-router would neither see nor be burdened with seeing the entire flat topology of the nearest zooming level 1. All TARA-routers, some by doing more, some by doing less, will participate in this well concerted process to produce the knowledge about these five topologies as well as how they can be combined to become one single TARA-map such that each TARA-router may find itself completely surrounded by TARA-links from the zooming level 1 map, which themselves are surrounded by TARA links from the zooming level 2 map, etc. - coarsely sketched (because there will also be strict links to some very remote node which can eventually only show up in the map of zooming level 5). The Google route planer tool is best suitable to demonstrate how TARA functions. On a slow computer you may even see the hereby needed geopatch subdivisioning when, upon changing the zooming level, the parts of the new picture pop up square by square. In addition, a (globally operating) ISP-network may communicate, internally by OSPF, all its internal TARA-links, no matter how many geopatches they would span, and add the resulting topology to the TARA-map.This may be utilized by some ISP-policy which rather wants to forward the packets internally than externally along the shortest path.From the TARA-map the proper tables and their contents will be derived which will enable the next-hop determination by means of one, respectively three table offsets. TARA will eliminate the scalability problem once and forever, i.e. even if the internet were a thousand or a million times bigger than it is today:In case the growing internet would require some adjustment, all it takes is to add some additional zooming levels, or some more intensive scale ratios. Note, although the internet is fairly small we nevertheless need to have at least 5 zooming levels (to avoid the Istanbul effect, see below). This also means that the to be applied scale ratios for computing the less zoomed maps will rather be like 1:4 than 1:10. Hummel Expires March 20, 2011 [Page 3] Internet-Draft TARA September 2010 2. Basic aspects and definitions Definition : A (m,n)-geopatch cluster is a matrix of m rows and n columns of (1,1)-geopatches. A (1,1)-geopatch is an area which is limited by two adjacent longitudes and two adjacent latitudes (resp. at the poles by two adjacent longitudes and one latitude). The TARA protocol shall standardize: - the number of zooming levels (e.g. five), - the clustering of (n,m)-geo-patches per zooming level, - and rules which determine the scale ratio for computing a geopatch'es/geopatch cluster's contribution for a next upper level topology Proposed clustering per Zooming level: Zooming level 1:There are 180x360=64800 (1,1)-geo-patches Zooming level 2:There may be 60x120= 7200 (3,3)-geo-patches Zooming level 3:There may be 30 x 60= 1800 (6,6)-geo-patches Zooming level 4:There may be 15 x 30= 450 (12,12)-geo-patches Zooming level 5:There may be 5x10= 50 (36,36)-geo-patches Numbering scheme: The (1,1)-geo-patches are numbered from 1 to 64800, starting at the South Pole with that (1,1)-geo-patch which is limited by the two longitude degrees 0 and 1 East, the South Pole and latitude 89 South, winding from there in East bound direction, while forming a full circle such that number 360 is assigned to that (1,1)-geo-patch, which is limited by the two longitude degrees 1 West and 0,and number 361 is assigned to that (1,1,)-geo-patch,which is limited by the longitude degrees 0 and 1 East and the latitudes 89 South and 88 South. While winding in East bound direction and while winding towards the North Pole, the last number 64800 is assigned to that (1,1)-geo-patch which is limited by the longitudes 1 West and 0, the latitude 89 North and the North Pole. The limiting line to the West and the limiting line to the South (resp. the South Pole) themselves will belong to the hereby bordered (1,1)-geo-patch. The geopatch number (geopatch#) is also called square degree#. Analogous is the numbering for (n,m)-geo-patch clusters. (m,n)-geopatch clusters of a particular zooming level >1 are also numbered in the Eastbound from south to north pole spinning fashion. Any router inside a particular (1,1)-geo-patch whose geopatch# = x1 may want to know the numbers x2, x3, x4, x5 of the (n,m)-geo-patch clusters it belongs to at the respective zooming levels 2, 3, 4, 5. Hummel Expires March 20, 2011 [Page 4] Internet-Draft TARA September 2010 They are: x2 = int ( ( x1 +8)/9 ) x3 = int ( ( x1 +35)/36 ) x4 = int ( ( x1 +143)/144 ) x5 = int ( ( x1 +1295)/1296 ) Deriving the (1,1)-geo-patch-# from the geographical coordinates: The mapping from geographical coordinates to the geo-location-ID may be done as follows: We introduce new LO_ngitude D_egree LOD and new LA_titude D_egree LAD, which are consecutive from 1 to 360 resp. from 1 to 180, i.e. without the East versus West resp.North versus South differentiation. If x is 0 (Greenwich) or some degree East of Greenwich then LOD = x+1. If x is some degree West of Greenwich then LOD = 360-x. If y is 0 (equator) or some degree North of the equator then LAD = 90 + y+1 If y is some degree South of the equator then LAD = 90-y Hence any (1,1)- geo-patch may be identified by {LOD, LAD} respectively by its number: square-degree # = (LAD-1) * 360 + LOD. Extension with respect to minutes: We introduce new LO_ngitude M_inute LOM and new LA_titude M_inute LAM, which are both numbers from 1 to 60 . If (0<=x<60) is some minute not West of Greenwich then LOM = x+1. If (0<=x<60) is some minute West of Greenwich then LOM = 60-x. If (0<=y<60) is some minute not South of the equator then LAM=y+1. If (0<=y<60) is some minute South of the equator then LAM = 60-y. So any square-minute geo-patch inside some (1,1)- geo-patch may be identified by: square-minute # = (LAM-1) * 60 + LOM. A square-minute encompasses its rim to its West and to its South. Extension with respect to seconds: We introduce new longitude second LOS and new latitude second LAS, which are both numbers from 1 to 60 . If (0<=x<=59) is some second not West of Greenwich then LOS = x+1. If (0<=x<=59) is some second West of Greenwich then LOS = 60-x Hummel Expires March 20, 2011 [Page 5] Internet-Draft TARA September 2010 If (0<=y<=59) is some second not South of the equator then LAS = y+1. If (0<=y<=59) is some second South of the equator then LAS = 60-y. So any square-second geo-patch inside some geo-patch square minute may be identified by : { LOS , LAS } In summary, the geo-location-id of any TARA-router respectively of any destination user is given by its TARA-Locator = { square-degree #, // Range 1 to 64800 16 bits square-minute #, // Range 1 to 3600 12 bits LOS, // Range 1 to 60 6 bits LAS // Range 1 to 60 6 bits }. Note: For practical reason we do not build a square-second value, see below. Note: Inverse mapping from TARA-Locator to the geographical coordinates is always possible, too. Finer granularity ? We may anticipate finer granularity to identify fractions of square seconds. But right now there is no urgent need for it. 3. TARA concept Analogously to Google-map several (e.g. five) internet topologies of different zooming levels shall be constructed by the concerted effort of all TARA routers. From some outside point of view there will be 5 maps. The nearest zoom topology will be the precise topology of the entire internet. By some algorithm the closer zoomed map will be skimmed for generating the less zoomed map - recursively four times. All TARA-routers all over the earth will learn/see the whole least zoomed map,whereas TARA-routers of a well confined geographical area will only see their respective closest zoomed map excerpt. All TARA-routers will contribute, especially border nodes which are adjacent to neighboring geopatches / geopatch-clusters, as to build these 5 maps. A strict protocol-based ordering (who mends on which piece) will make sure that the map pieces will fit together at their rims.Furthermore, the maps of zooming levels 2,3 and 4 must be made scrollable such that each TARA-router may conceive itself being fairly at the center of all seen upper maps. By this "scrolling" the Istanbul effect will be avoided. Istanbul effect means: It would be bad if a city map of Istanbul Hummel Expires March 20, 2011 [Page 6] Internet-Draft TARA September 2010 contained the European part with all the details, but for the Asian part just what you get about Istanbul from a road map for whole Asia. This also shows that at least 5 zooming levels are needed although the internet with just 10 000 DFZ-routers is fairly small. Note: The maps of geopatch and geopatch-clusters a TARA-router would hereby get might be viewed as hierarchical routing. However, catering 64800 hierarchies rather than just one! Also: There is no stretch factor 3 or 17 to be observed. The way how the loose TARA-links are constructed will always comply with stretch 1. By means of a simple BGP UPDATE message extension a TARA router may advertise its existence, i.e.: - the originating TARA-router A, its IP address and its TARA-locator and its adjacent TARA-links i.e.: - the zooming level (1 to 5) indicating the respectively zoomed map - the respective geopatch (cluster) # - the remote endpoint TARA-router B, with its - IP address and its - TARA-locator - the weight of this TARA-link (= 1 if strict link, =number of its hops if loose link) - link type (strict, loose, "GRE-tunnel" crossing some non-TARA network part) - purpose of propagation ("for building upper maps" or for "scrolling") - more (like additional info for scrolling,or optionally:explicit list of geopatch numbers the two link-adjacent TARA-routers would represent) A TARA-link shall be advertised by that endnode which has the smaller IP address.During the incremental deployment phase these UPDATE messages,for zoom level 1, will be disseminated worldwide. Thereafter, dissemination may be well-scoped according to the originator's TARA-locator and the zooming level information. A TARA-link is of type "strict" if both ends of the physical link are TARA-routers. A TARA-link is of type "GRE-tunnel" if a single GRE-Tunnel is needed to "connect its endpoint TARA-routers across classical internet routers. Hereby a to be standardized rule is required for assigning an adequate weight value (e.g. based on classical BGP path length information, or based on the spheric geo- distance).A TARA-link is of type "loose" if it is rather a path which consists of multiple concatenated TARA-links, each of which is of any of the three link types. Hummel Expires March 20, 2011 [Page 7] Internet-Draft TARA September 2010 At first a TARA-router will advertise its existence and also that it can reach prefixes of length zero (default mapper). It will be propagated worldwide by BGP UPDATE. Non-TARA-routers will only evaluate classical information, whereas TARA-routers will recognize the contained TARA-information. Later on, TARA-routers will also advertise their strict adjacent TARA-links which shall be propagated onwards such that miniclusters are generated where each participating TARA-router will get to know the topology of this mini-cluster. One of them needs to be identified which shall establish a "GRE-Tunnel"-TARA-link to some nearest TARA-router inside the same geopatch. Peu a peu all TARA- routers inside some geopatch will learn their common intra-geopatch topology. Sustained by GRE-tunneling technique the TARA-link propagation can be done such that only TARA-routers will get to see the propagated TARA information. Furthermore, a TARA-router, whose absolutely nearest neighboring TARA-router is from some other geopatch, shall establish a respective strict ore GRE-type TARA-link and propagate it intra- geopatch wide. In case there is still no TARA-link between two adjacent geopatches A and B although nA and nB TARA-nodes exist and are known by all nA + nB TARA-routers, some algorithm shall be applied to select a pair of TARA-routers (out from nA * nB many combinations) which shall establish a TARA-GRE-Tunnel as to interconnect the two adjacent geopatches. An analogous procedure may apply that leads to establishing a TARA- link for some higher zooming level's topology in order to inter- connect two adjacent higher-level geopatch clusters ( because at lower levels at least one of the adjacent geopatch /geopatch cluster is completely without any TARA-router). Additionally, TARA-routers of different geopatches may realize that there is a strict TARA-link between them, whereby their (1,1)-geopatches are not adjacent ( Note: Apart from geopatches adjacent to the poles, each geopatch is surrounded by 8 geopatches: to the North, East,South,West,NE,SE,SW,NW) . We have to identify the smallest zooming level i for which both endpoints have the same geopatch cluster-# xi (i from 3 to 5) and propagate a respective TARA-link at that particular zooming level i. As a result, all TARA-routers of the same geopatch will learn the entire set of TARA-links which form an intra-geopatch topology and also TARA-links to the outside of their geopatches, and also some of the TARA-links of upper zooming levels' topologies. TARA-link Hummel Expires March 20, 2011 [Page 8] Internet-Draft TARA September 2010 propagation may be done by some flooding technique and also with the help of GRE-tunneling such that only TARA-routers get to see these BGP UPDATE messages carrying TARA-links. They will be able to limit spreading to neighboring TARA-routers such that it is only flooded among TARA-routers within the own geopatch resp. own geopatch cluster. By means of a very TARA-essential algorithm/mechanism each intra- geopatch TARA-router is enabled to compute the same identical well skimmed representative topology for that geopatch which shall become part of the next upper zooming level's topology. Some to be standardized rules will be required as to determine the adequate scale ratio to be applied. A desert type area with only a few nodes might get scale ratio 1:1, whereas a metropolitain area with many nodes may need scale ratio 1:10. For comparison: A map for the Death Valley desert contains almost each shack whereas a not so detailed map for a huge city might not even contain all streets. I.e. a standardized table shall prescribe which scale ratio is to be applied for any given density of nodes. Also note that the resulting strict/loose TARA-links will have weights equal to the number of hops between their endpoint TARA- nodes. Border nodes, adjacent to neighboring geopatches will play an important role. A border node will communicate all computed upper zoom TARA-links to the neighboring geopatch where they are disseminated all over. Inversely: It will receive such links from the neighboring geopatch for dissemination all over the own geopatch. This process needs to cover all geopatches of some well identified cluster. The set of all TARA-links of zoom level 2 of the respective geopatch cluster will form the basis for computing a well skimmed topology for becoming part of the zoom level 3 topology, etc. There will be recursively- 4 times such a process as to compute all upper zooming levels' topologies. The computation will of course consider that there are already some pre-set TARA-nodes and TARA-links of whichever upper zooming level's topology as described above. When all topologies of all zooming levels are computed we can take for granted that each TARA-router will see the total TARA-topology of its own geopatch (zooming level 1) as well as the total TARA- topology of the highest zooming level 5. It will see TARA-topology excerpts of the zooming levels in-between. In order to avoid the Istanbul effect, we need some "scroll" mechanism, i.e. some additional mechanism for dissemnating TARA-links for the zooming levels 2,3 and 4, such that each geopatch may conceive itself being the center geopatch of the entire world. I.e.geopatches at the rim Hummel Expires March 20, 2011 [Page 9] Internet-Draft TARA September 2010 of some geopatch cluster shall also get to know about TARA-links of the near surrounding although they haven't been involved in creating them. Finally, each TARA-router must be enabled to combine the viewed topologies such that the more detailed topology replaces the respective piece of the next upper zooming level's topology as to form one single flat TARA-map. Hereby special attention is to be given to those TARA-links which perform the binding, i.e. which have to be split into a lower level link-part and an upper level link-part (with a third node that connects the two pieces). Filling and using TARA- forwarding tables: Based on its TARA-map a TARA-router computes the entries of its TARA-forwarding tables as described by the following. Based on the destination TARA-locator as of some received IP packet's prepended TARA-header a TARA-router retrieves the next hop information from its TARA- forwarding tables as described by the following as well. Destination is outside from the current router's (1,1)-geo-patch: For the sake of forwarding to another (1,1)-geo-patch the current router shall maintain a table t1 with 64800 next-hop entries. By means of one Dijkstra it computes the next-hop to all nodes of the TARA-map. At first let's consider those nodes which have a different geopatch number than the current router itself. Among them, we select the one which is nearest according to their Dijkstra path lengths and enter with proper geopatch# offset the respective bestnext hop into table t1. There will be many t1-offsets with would probable index some ocean or desert area where there is no single TARA-router.These t1-offset elements will be some default value but should never be used. There may be others for which the TARA-map doesn't have some node. Here, we should look for the relative closest TARA-router which happens to be in the TARA-map, and have entered its respective (proxy) best next hop here as well. Destination is inside of the current router's (1,1)-geo-patch: We cannot afford a 3600 times 3600=12,960,000 entries sized table, i.e. a matrix for each square second. Hence, for the sake of forwarding to any TARA-router x from the current router's (1,1)-geo-patch we employ tables t2, t3, t4. Table t2, indexed by TARA-router X's square-minute number, will refer to some table t3. Hummel Expires March 20, 2011 [Page 10] Internet-Draft TARA September 2010 Table t3, indexed by TARA-router X's LOS, will refer to some table t4. Table t4, indexed by TARA-router X's LAS, will contain the next hop towards X. or an indication that the current router is already the egress. In this case forwarding shall take place classically. There will be just one single table t1 with 64800 entries. There will be just one single (sparsely filled) table t2 with 3600 entries ( a minority of these entries refer to some particular t3-tables) There will be multiple tables t3 with 60 entries each. There will be multiple table t4 with 60 entries each. When an IP-packet with a prepended TARA-header is received the next hop is determined as follows: Take the received destination TARA-locator. Is its square-degree# equal to the current router's square-degree# ? If No, index table t1 with the received square degree# and retrieve next hop info. Else take the received square minute# to offset table t2 for retrieving a particular table t3. Index table t3 with the received LOS for retrieving a particular table t4. Index table t4 with the received LAS for retrieving the next hop information. The hereby retrieved next hop information will indicate the physical link for next hop forwarding plus eventually some instruction to GRE-encapsulate the packet prior forwarding to the endpoint node of this next hop TARA-link. Or: It indicates that the current router is the endpoint of TARA forwarding. As a result next hop lookup becomes very fast and will enable Moore's law applicability to internet packet forwarding. No caching is required either. In case the best hop information shall be replaced by some other (due to congestion or for traffic balancing reasons), the information of the LAS-indexed t4-table ( or the square-degree#- indexed t1 table) can be replaced (e.g. temporarily). This means, even alternative forwarding can be done equally fast, i.e. wouldn't jeopardize Moore's law applicability. 4. Starting TARA forwarding: At first, packet forwarding is explained while assuming that TARA were completely deployed. Thereafter several solutions are shown how to do packet forwarding while TARA is about to be introduced. Hummel Expires March 20, 2011 [Page 11] Internet-Draft TARA September 2010 4.1 TARA - fully deployed: The source user sends a DNS-lookup request message and is returned not only the destination IP address but also its geographical coordinates according to the so far experimental RFC1712. The source user will prepend a TARA-header which contains the TARA-locators of both source and destination. Or: The ingress TARA-router intercepts the returned response of the DNS-lookup,reads the contained geographical coordinates, derives the respective TARA-locator, and stores it in such a way that it can be retrieved based on the respective IP address. The ingress TARA-router prepends a TARA-header and forwarding is done according to TARA. This alternative, additional solution will enable TARA- forwarding without involving end-users. 4.2 TARA - incremental deployment phase: It may happen that the DNS-lookup request message is not returning the geographical coordinates of the destination, nor do neither the source user nor any router along the packet's path know the destination's TARA-locator. Then forwarding must be done classically. I.e. then even the TARA-router must still operate with its traditional FIB and RIB in this situation. It may happen that the source host has appended a TARA-header, but the ingress router is not a TARA-router.By assuming that the destination's TARA-xTR doesn't advertise prefixes with respect to its reachable users,but by also assuming that any TARA-router propagates reachability for prefix length zero, that some TARA-router which is nearest to the ingress router, i.e. some TARA-ITR, will attract the packets and will then proceed with TARA forwarding. In this was it may as well attract packets with no prepended TARA- header and may act as proxy:consult DNS,inversely lookup the TARA- locator,prepend a TARA-header,... Indeed, TARA routers would stop advertising reachability information with respect to attached users! As a result, the classical FIBs would shrink the more TARA is deployed and may extinct finally. How to forward the TARA-locators? By means of a TARA-header, -shim/label , IMAC-embedded? TARA-header: LISP uses a prepended LISP-header to forward the IPv4 addresses of ITR and ETR. Likewise, TARA may prepend a TARA-header (and adopt whichever useful LISP-header detail). Hummel Expires March 20, 2011 [Page 12] Internet-Draft TARA September 2010 TARA-shim/label: The TARA-locator could be understood as a globally significant label, as opposed to the MPLS-labels of local significance. TARA-forwarding as a new form of label-switching ? TARA-locators embedded in MAC address: MAC-addresses just provide a great probability of uniqueness. Why can't the initial value be replaced by some other but as well globally unique data which is also routable ? We are all used to "getting a weird initial password" which we then may modify as to please ourselves?! Having an (extendable) TARA-header would be the best solution among all, because the not mentioned alternative, embedding the TARA-locator into the IPv6-address, though simpliest at all, is not a real alternative, because IPv4 must not be neglected (particularly, as there is no necessity for neglecting IPv4 ). Indeed, a new TARA-header would enable to place additional flags and attributes into this header for further capabilities which will go far beyond today's state-of-art routing. 5. Further aspects and advantages 5.1 TARA intra-domain: It is quite obviously that topology-aware TARA-routing would also fit for topology-aware intra-domain routing. Advantages: Intra- domain address prefix building and dissemination isn't required anymore either. The same fast forwarding that enables Moore's law application will happen also intra-domain ( about 20 times faster next hop retrieval). The TARA-map as of above should be enhanced with the intra-domain TARA-closest zoom map and made available for the intra-domain nodes, wheras a respective less zoomed map (as would please the ISP's policy) may be advertised to the external internet. Where shall TARA-forwarding end ? Currently at some ETR-DFZ- router.Indeed, the current TARA concept assumes globally unique TARA- locators of the xTR-DFZ-routers, which are assigned by these DFZ- routers to the individual end users too. Obviously the chance is small that two DFZ-routers would come up with the same TARA-locator. Hummel Expires March 20, 2011 [Page 13] Internet-Draft TARA September 2010 In case of a clash however there are several ways to overcome this clash: a) negotiation protocol between these 2 nodes b) cheating while DNS registering (it is not important whether the LAS and LOS values are absolutely in compliance with the DFZ-routers geographical location because shortest path means least amount of hops and not shortest spheric arc.) In a long-term view, TARA-forwarding may end at the egress router or even at the host itself: The end user may register itself at the DNS indicating some IPv4 ? some HIT ? some name? Or some E164 ? Extending the network so that the end users are also nodes wouldn't be a big problem: It means that there are several nodes with the same identical geographical coordinates, eventually. They and also their neighboring pre-ultimate hop nodes should be aware of what additional information needs to be checked for proper forwarding and/or proper acknowledg- ment to be the right or wrong destination. Also, we can always introduce one ore two additional zooming levels so that the total number of nodes of the entire internet becomes billions rather than 10 000 (in case of DFZ-routers). 5.2 Multihoming: One IPv4-addressed end-user may have several TARA-locators (similar to LISP).Which of them shall be in action ? The TARA-header might convey e.g. one armed and one disarmed TARA-locator so that any router inside the network were enabled to swap their positions in this header. 5.3 Enhanced Multipath: Loopfree detours and even detours via more remote nodes (e.g. crankback) can be enabled. Each node can, with respect to a given destination TARA-locator classify ALL its adjacent links: From best (and ECMP-best), to detouring via equi-distant routers, to detouring via more remote routers, to dead end i.e. no goes. All it takes are a few flags in the TARA-header which eventually indicate a current detour-type ("detour via neighbors which all have the same distance to the destination", or "detour via more remote explicitly conveyed VIA-nodes", "detour because of congestion"). Other types may envision time-of-day routing, east-bound /west-bound routing, or Multihoming aspects (Multihoming is just a special sub-aspect of Multipath. However, it is quite obvious that with DV-based routing you cannot do any better than ECMP. Hummel Expires March 20, 2011 [Page 14] Internet-Draft TARA September 2010 5.4 Mobility: TARA would enable mobile IP without the need of home-agents or similar constructs (care-of-address servers, TRs,..). The DNS might be the only place where the user's current location is stored, i.e. no other entities that have to keep some respective "state". An immediate DNS update is necessary only if the user moves to a different geopatch i.e. finds there a new hosting DFZ-router. If it roams within the same geopatch and finds there a new hosting DFZ- router a geopatch-scoped broadcast search might be initiated by any DFZ-router inside this geopatch as to find the actual hosting node. Adequate algorithms may take care that loopfree broadcast search messages can be sent out reachingg all nodes within the indicated geopatch. 5.5 State-less Multicast & mp2mp to millions of destinations: Cascade Tree routing will outperform all current Multicast-address based models. It may also be used for UNICAST download requests that occur within some small time window. It would also be the best remedy ever for fighting DoS attacks: Most probably the burden would be shifted to the attackers while the attacked sender keeps sending n-times with n equals the degree of the cascading nodes.Assuming cascade degree 10 and assuming 20 hops being the average p2p path 99,5 % of the involved routers won't need states. 5.6 Traffic balancing and congestion handling: The TARA map represents an intra- and inter-domain topology of reasonable size which allows some TARA-(transit) router, to recognize with respect to some passing traffic flow the respective well confined upstream surrounding and to exchange p2mp and mp2p traffic load relating notification messages in a well concerted way for a) avoiding congestions in the first place, b) handling congestions in the best possible manner such that the point of congestion is not just re-located. Each node may algorithmically recognize the entireness of this upstream surrounding, in particular its uppest rim. Some of them may continue with forwarding packets towards the congested node(s) while others may easily use /impose the use of a bypassing alternative route. It is quite obvious that this requires topology awareness which distance-vector based routing will never ever provide !! Hummel Expires March 20, 2011 [Page 15] Internet-Draft TARA September 2010 5.7 Multi-Protocol-TARA forwarding The TARA-header doesn't care which other type of header it is prepended to. It may be an IPv4-Header,or an IPv6-header, or a new E.164-Header (!) with no enum-mapping, or any HIP-Header,etc. 6. Conclusion Though fundamentally different in spirit, the required protocol extensions won't be such major. 2 or 3 years for protocol development will probably be sufficient. Thereafter TARA may be the base for many new extensions towards a more intelligent network layer and for the benefit of services we cannot even imagine today. 7. Authors' Addresses Heiner Hummel www.hummel-research.de Email: heinerhummel@aol.com Hummel Expires March 20, 2011 [Page 16]