Evaluating the benefits of the locator/identifier separation

Abstract

Since recent years, it has been recognized that the existing routing architecture of today's Internet is facing scalability problems. Single numbering space, multi-homing, and traffic engineering, are making routing tables of the default free zone to grow very rapidly. Recently, in order to solve this issue, it has been proposed to review the Internet addressing architecture by separating the end-systems identifiers' space and the routing locators' space.In this paper we review the most recent Locator/ID separation proposal and explore the benefits that such an architecture may bring. In particular, we evaluate the improvements that can be achieved in terms of routing tables' size reduction and traffic engineering.

A Deep Dive into the LISP Cache and What ISPs Should Know about It

“…Evaluating such kind of benefits is beyond the scope of this paper. Further information can be found in the work of Quoitin et al [22] and Iannone et al [12].…”

“…Differently from the current architecture, where one single namespace, namely the IP address space, is used for both indentifying and locating end-systems, in the Locator/ID Split paradigm two different namespaces are used: the ID space and the Locator space, to respectively identify and locate end-systems. Such a separation aims at solving the scalability issues that the current Internet is facing [19], mainly concerning the continuously increasing BGP routing table [1], but also concerning addressing, mobility, multi-homing [22], and inter-domain traffic engineering [25].…”

Locator/ID Separation Protocol (LISP) Impact

“…Quoitin et al [QIdLB07] show that the separation between locator and identifier roles at the network level improves the routing scalability by reducing the Routing Information Base (RIB) size (up to one order of magnitude) and increases path diversity and thus the traffic engineering capabilities. [IB07] and [KIF13] show, based on real Internet traffic traces, that the number of mapping entries that must be handled by an ITR of a network with up to 20,000 users is limited to few tens of thousands; the signaling traffic (i.e., Map-Request/Map-Reply packets) is in the same order of magnitude similar to DNS request/reply traffic; and the encapsulation overhead, while not negligible, is very limited (in the order of few percentage points of the total traffic volume).…”

Managing interdomain traffic in Latin America: a new perspective based on LISP

“…First, it does not introduce major changes to the routing system, and therefore it might be feasible to implement and deploy in the near future. Second, it has the potential to significantly reduce the size of the global routing table [5]. Third, the mapping system brings a wide set of TE opportunities, which in principle, can reach a granularity of a /32 prefix without impacting on the size or dynamics of the global routing table.…”

“…For instance, Quoitin et al [5] show that the size of the global routing table can be reduced by roughly two orders of magnitude with LISP. That work also shows that LISP provides improved interdomain TE capabilities using a nondisruptive approach.…”