Project topics and materials
Get Complete Project Material File(s) Now! »
LISP architecture
The Locator/Identifier Separation Protocol (LISP) separates the traditional IP address role into two logical sub-spaces: (i) Endpoint IDentifier (EID) and (ii) Routing LOCator (RLOC). Both of them are the conventional IPv4 (32-bit) [105] or IPv6 (128-bit) [45] addresses. The EID is the identifier of hosts, which is locally routable in the LISP-site. Normally they are the addresses of source and destination hosts. Within the same LISP-site, the hosts can directly communicate with each other via EIDs as in a legacy IP network. The host gets a destination EID in the same way it obtains the destination IP address today, for instance through a Domain Name System (DNS) [89] lookup or Session Initiation Protocol (SIP) [107]. RLOCs denote the attachment points of EIDs in the Internet topology, i.e., the source/destination address of the edge routers, behind whom theEIDs can be found. RLOCs addresses are used to forward the packets in the core Internet.
When packets are transferred between two different LISP-sites, an encapsulation on the edge router is needed: the source and remote destination EIDs are in the inner packet header, while the source and destination RLOCs are in the outer header. The EID-prefixes are not necessary to be announced on the Internet core, so the BGP routing table size can be reduced. Similarly, in stub networks, it is not necessary to know the routing information of core Internet any more. The aforementioned encapsulation and forwarding operations are the responsibilities of LISP Data Plane. More details are introduced in Sec. 2.1.1. To bind the EIDs and RLOCs, a new network entity named Mapping Distribution System (MDS) is used, whose front end is consisting of Map Resolver (MR) and Map Server (MS) [56]. The MDS is not only able to provide the mapping information between the EIDs and RLOCs for the LISP-sites (we simply call them LISP Map-Replies), but also indicate which addresses are not LISP sites and have no RLOCs, meaning that are part of the legacy Internet (these are called NegativeMap-Replies). The Control Plane is described in Sec. 2.1.2.
LISP Data Plane
The LISP Data plane mainly takes care of the encapsulation and decapsulation operations done at the source and destination networks. LISP basically provides a level of indirection through a tunneling mechanism over the core Internet (the so called Default Free Zone (DFZ)), in order to provide end-to-end communication. More specifically, any host willing to communicate with another host residing at remote LISP-site, uses its own EID as source address and the EID of other host as destination address to generate regular IP packets. These packets are first transferred as usual to the border router, called Ingress Tunnel Router (ITR). ITR performs a mapping lookup in its Cache, or in case of miss, it queries the MDS for the mapping information. Then the ITR encapsulates the regular IP packets into a LISP packet by adding a tunnel header [47], where the RLOC of the ITR is used as source address and the destination RLOC as destination address. After encapsulation, the LISP packets are forwarded over the core Internet. When arriving at the destination border router, called Egress Tunnel Router (ETR), the LISP packets are decapsulated (i.e., the tunnel header is removed) and transferred to the destination host. A device which acts as both an ITR and an ETR is denoted as xTR. Mappings are stored in two data structures on the xTRs: the LISP Database and the LISP Cache. The LISP Database is populated by configuration and stores all known EID- to-RLOC mappings, for which the EID-Prefixes are behind the xTR. On an ITR, this helps select a source RLOC used in encapsulation. While on an ETR, it allows to verify whether itself is the proper ETR connecting to the destination EID, so that such ETR is able to forward the decapsulated packets to the final destination.
Communication between two LISP-sites
We use Fig. 2.4 as an example to describe how the LISP packets are processed in details in the case of the packets exchange between two LISP-sites. When the host in the ASs (Autonomous System) communicateswith the host in the ASd, it uses EIDs as source address and EIDd as destination address. After the conventional IP routing to xTR1 (the function of ITR and ETR are combined together in Fig. 2.4) labeled as « 1 », ITR1 first checks in its mapping cache [66] to find out the association between EIDd and its RLOC. If there is no record, it sends a Map-Request to Map-Resolver (MR), labeled as « 2 ». MR searches which Map-Server (MS) stores the mapping information of EIDd and forwards theMap-Request to that MS. If MS is authoritative (i.e., acts as a proxy), it directly returns back aMap-Reply containing the mapping information (this procedure is not labeled in the figure). If not, after forwarding the Map-Request within MDS with the procedure described in Sec. 2.1.2 to MS and then to the destination side (label « 3 »), xTR1 receives a Map Reply from one of ETRs of EIDd (label « 4 »). If theMap-Reply shows that the priority of ETR3 is higher than ETR4, then the ITR1 encapsulates the packets by adding RLOCETR3 as the destination address and RLOCITR1 as the source address in the outer header and sends the encapsulated packets through the Internet as labeled « 5 » in Fig. 2.4. Once ETR3 receives these packets, it decapsulates and forwards them by using the original IP packets (label « 6 »). If the destination site is not a LISP-site, theMR directly returns back theMap-Reply without mapping information to ITR1. Based on LISP architecture, there are three types of outcomes for a query:
• LISP Map-Reply, means that the queried IP address belongs to a LISP site (i.e., EID) and the Map-Reply contains the mapping information for this site, including: the association between the EID-prefix that queried EID belongs to, and the list of RLOC tuples <RLOC, Priority, Weight> of the destination site.
• Negative Map-Reply, means that the prefix covering the queried IP address belongs to a non-LISP site (i.e., conventional site), and the Map-Reply contains no mapping information. We consider these two kinds of replies as successful queries.
• No Map-Reply, means that the xTR does not receive any reply during a certain time. According to the standard described in [47], the time-out is set to 3 seconds. But this value can be modified in the implementation to adapt the experiment needs. In this case, we consider the query as failed.
Table of contents :
0.1 Introduction
0.2 Motivation
0.3 Contexte
0.3.1 Architecture LISP
0.3.2 Interfonctionnement avec Internet de la légitimité
0.3.3 LISP mobilité
0.3.4 LISP Beta Network
0.3.5 LISP-Lab platform
0.3.6 LISPmon
0.4 Évaluation de LISP mapping system
0.4.1 Vue générale des mesures
0.4.2 Metrics
0.4.3 Résultats
0.5 LISP-Views: moniteur du LISP mapping system
0.5.1 Motivation
0.5.2 Déscription de LISP-Views
0.6 Validation de LISP-Views
0.7 Évaluation de la performance d’interfonctionnement LISP grâce à RIPE Atlasxxiv
0.7.1 Méthodologie de mesure
0.7.2 Résultats des Ping
0.7.3 Résultats des Traceroute
0.8 Analyse de la mobilité LISP et de la mise en oeuvre de ns-3
0.8.1 Implémentation de LISP sur ns-3
0.8.2 Analyse théorique
0.9 Conclusion et travail futur
0.9.1 Contributions majeures
0.9.2 Discussion & travaux futurs
List of figures
List of tables
Acronyms
1 Introduction
1.1 Motivations
1.2 Contributions
1.3 Manuscript organization
2 LISP overview
2.1 LISP architecture
2.1.1 LISP Data Plane
2.1.2 LISP Control Plane
2.1.3 Communication between two LISP-sites
2.2 Interworking with legency Internet
2.3 Mapping cache update mechanisms
2.3.1 Solicit-Map-Request (SMR)
2.3.2 Map-Versioning
2.4 LISP mobility
2.4.1 LISP Mobile Node (LISP-MN)
2.4.2 MN mobility in LISP-Site
2.4.3 LISP-MN mobility in LISP-Site
2.4.4 LISP-MN mobility in non-LISP-Site
2.4.5 LISP-MN mobility between LISP-Site & non-LISP-Site
2.5 LISP alternative use-cases
2.5.1 LISP traffic engineering
2.5.2 LISP transition between IPv4 and IPv6
2.5.3 LISP SDN
3 Relatedwork
3.1 LISP platforms
3.1.1 LISP Beta Network
3.1.2 LISP-Lab platform
3.2 LISP monitoring tools
3.2.1 LISPmon
3.2.2 LIG
3.2.3 RIG
3.2.4 Monitoring tools shortcomings
3.3 LISP implementations
3.3.1 LISP implementations
3.3.2 The LISP simulation gap
3.4 LISP mapping system evaluation
3.4.1 Current studies
3.4.2 The incomplete puzzle of MDS evaluation
3.5 LISP network evolution
3.5.1 Updating LISP measurements
3.6 LISP interworking with legacy Internet
3.6.1 PxTRs evaluation: an incomplete picture
3.7 LISP mobility
3.7.1 Open issue in LISP mobility
3.8 Troubleshooting issues
3.9 Other LISP related studies
3.9.1 LISP cache performance
3.9.2 LISP security
3.9.3 The Maximum Transmission Unit (MTU) issue
4 Evaluation of LISP mapping system
4.1 Methodology
4.1.1 Measurements overview
4.1.2 Metrics
4.2 Mapping system stability evaluation
4.3 Mapping system consistency evaluation
4.3.1 Consistency evaluation by MR
4.3.2 Consistency evaluation by VP
4.4 Summary
5 LISP-Views:LISPmapping system monitor
5.1 Proposed monitoring architecture
5.1.1 Motivation
5.1.2 Description of LISP-Views
5.2 LISP-Views validation
5.2.1 Methodology
5.2.2 LISP-Views vs. LISPmon
5.3 Dissecting LISP with LISP-Views
5.4 Summary
6 Assessing LISP interworking performance through RIPE Atlas
6.1 Experiment resources
6.1.1 RIPE Atlas
6.1.2 Alexa
6.2 Measurement methodology
6.2.1 Dataset 2015
6.2.2 Dataset 2016
6.3 IPv4 Ping results from Dataset 2015
6.4 IPv4 Ping results from Dataset 2016
6.5 IPv6 Ping results
6.6 Traceroute-related results
6.7 Summary
7 Analysis of LISP mobility and ns-3 implementation
7.1 NS-3
7.2 Basic LISP implementation on ns-3
7.3 LISP mobility extensions on ns-3
7.3.1 Implementation of LISP Data Plane
7.3.2 Implementation of LISP Control Plane
7.3.3 Modification of DHCP client to support LISP mobility
7.3.4 Integration of TUN net interface card
7.4 Theoretical analysis
7.4.1 LISP-MN in non-LISP-Site
7.4.2 MN in LISP-Site
7.4.3 LISP-MN in LISP-Site
7.5 Summary
8 Conclusion and futurewrk
8.1 Major contributions
8.1.1 Evaluation of LISP mapping system
8.1.2 LISP-Views: LISP mapping system monitor
8.1.3 Assessing LISP interworking performance through RIPE Atlas
8.1.4 Analysis of LISP mobility and ns-3 Implementation
8.2 Discussion & future work
8.2.1 Evaluation of LISP mapping system
8.2.2 LISP-Views: LISP mapping system monitor
8.2.3 Assessing LISP interworking performance through RIPE Atlas
8.2.4 Analysis of LISP mobility and ns-3 Implementation
References
