TARA (Topology Aggregating Routing Architecture) is a novel architecture which allows to generate a map of the Internet. TARA allows to maintain and compute a precise topology of the near surrounding and lesser zoomed topologies the more remote they are. In the context of TARA, nodes are identified with “locators” which are derived from longitude/latitude degrees/minutes/seconds. TARA is designed to satisfy advanced traffic engineering such as computing QoS-inferred paths or non congested paths. TARA achieves these goals without requiring an increase of RIBs and FIBs. TARA solves also the issues of dynamic update churn as currently experienced in BGP-based Internet. TARA is also designed with mobility requirements in mind. Indeed, Mobility is supported without requiring dependency on home agents or care-of-address servers. Note, the Time-To-Live mechanism is neither needed nor used in TARA-forwarding. TARA supports various multicast, broadcast, MP2P (multipoint-to-point), anycast and MP2MP (multipoint-to-multipoint) communication schemes. In particular a stateless concept for multicast is outlined; this concept may serve as a pattern for anycast and MP2MP applications. TARA is fully prepared to cope with the IPv4-unicast address depletion issue.
TopIntroduction
TARA is a completely different architecture compared to the current state of the art. It adopts a novel approach to solve the issues encountered by current Internet routing architectures.
TARA proposes a new concept which is based on new enhancements of existing protocols (e.g., BGP, OSPF, IS-IS) such that any TARA router from a particular well-determined geographical region will get to know all TARA links that interconnect any two TARA routers from that region, no matter to which customer or service provider networks they belong to. All TARA links from a given region will form a topology for which a well-skimmed representative topology “of lesser zoom” will be computed (consisting of a subset of its nodes and respective path links which interconnect them) and combined with alike skimmed topologies for neighboring regions. The combined topology will serve as a basis for computing an even lesser zoomed topology, representing the respectively enlarged area. Altogether and by four recursive cycles, five maps of less and lesser zoom for the entire Internet will be created. As a result, a TARA router would maintain a TARA map with itself fairly in the middle, surrounded by the complete and precise topology of its region, which is surrounded by less and lesser zoomed topologies the more remote the Internet routers are located. Towards each node of the TARA map a shortest, as well as QoS-inferred and current traffic load sensitive, routes will be computed and their respective first hops stored in a new type of FIB (Forwarding Information Base). In case a next hop shall be retrieved for a packet whose destination node won't be in the TARA map, the geographically closest node from the TARA map will be selected and the respective next hop looked up.
TARA would use BGP and OSPF/IS-IS for installing a TARA-Overlay network (similar to RFC2457/4364-MPLS-VPNs), however not for building multiple private networks. If TARA is widely deployed, this would eliminate completely the scalability issue encountered by current Internet architecture. This is achievable because TARA routers won’t originate reachability prefixes for locally attached hosts nor forward received reachability prefixes from stub areas. For that aim, TARA can be deployed incrementally without requiring all BGP speaker to be TARA-aware.
TARA is a true location/Identifier separation solution. TARA locators indicate the location information. More precisely; there are 64800 spherical rectangles, resp. triangles at the poles, limited by consecutive longitude and latitude degrees, herein called geopatches. Their numbering and further intersection due to minutes and seconds will form the Unicast TARA Locator.
The unicast TARA Locator of a particular (destination) host shall be retrievable by DNS look-up queries. IP packets destined to a remote host are then forwarded to the identified egress router without ensuring whether the destination is reachable from there or not. If not, and if the destination is a mobile host, a well-scoped broadcast search will be preceded.
The aforementioned capabilities (i.e., computing less zoomed maps and doing well-scoped broadcast) are two from many more examples which are based on All Links Spanning Tree (ALST) computations. As it will be shown below, an ALST[d] is built by converting all network links to arcs which are, loop-free, bound to destination/root node d. A sub-tree thereof is the Dijkstra tree, herein called All Nodes Spanning Tree ANST[d].
While, by starting from any arbitrary node, Dijkstra (i.e., the ANST[d]) yields just one path towards d. The ALST[d] yields multiple shortest and multiple detouring paths (i.e., arc sequences). With some applied caution, i.e. by bestowing the forwarded packet with proper detour process description, additional paths are enabled where arcs are even passed in tail-ward direction. Altogether, any router can properly judge how each of its adjacent links would serve packet forwarding to some given destination node, from being a “best hop” to being a “no-go.” Even more, any individual router can do so with respect to all other network nodes’ adjacent links as well, which enables a 100% routing orientation such that there is no reason for worrying about loops anymore. In this context, the need for a TTL-based mechanism might be subject to re-consideration. The rationale adopted by TARA is endless loops can be prevented rather than reported.