Internet DRAFT - draft-hummel-tara
draft-hummel-tara
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]
