Map and Encapsulation Approaches

The map-and-encap approach, as depicted in Figure 2.6, is based on the mapping and encapsulation processes as follows. A source host, on a domain sending a packet to a destination, inserts the source Endpoint Identifier (EID) and the destination EID in the packet header (Figure 2.6:1). When the packet arrives at the border router of the same domain, the Ingress Tunnel Router (ITR) performs the mapping between the destination EID and the Routing Locator (RLOC) (Figure 2.6:2-mapping phase). After, ITR encapsulates the packet and sets the destination address to the RLOC retrieved in the mapping phase (Figure 2.6:3-encapsulation phase). Finally, the packet arrives at the destination domain, on which a border router, the Egress Tunnel Router (ETR), performs the decapsulation and the delivery to the destination EID (Figure 2.6:4). This approach supports both IPv4 and IPv6, leaving end hosts unchanged, and minimizes modifications in the routing system.

ISP2 ISP1 src S dst D ETR ITR 1 2 3 4

1 - Send {EID_S, EID_D} 2 - Map RLOC = EID_D

3 - Encapsulate {{RLOC} {EID_S}} 4 - Decapsulate {EID_D}

EID - Endpoint Identifier RLOC - Routing Locator ITR - Ingress Tunnel Router ETR - Egress Tunnel Router

Figure 2.6: Map and encap approach

2.7.3.1 Locator Identifier Separation Protocol

Locator Identifier Separation Protocol (LISP) is a map-and-encap protocol [Dave, 2008] aiming to improve site multihoming. LISP decouples site addressing from provider addressing, and reduces the overhead associated with routing tables (e.g. size and latency lookup operations). To implement such goals, LISP specifies the data plane on which the mapping and encapsulation processes take place, and the control plane to manage the EID-RLOC mapping system. Since LISP only defines the messages for querying data and receiving information from the mapping system, it adopts a flexible

design that allows different solutions for a mapping system. The proposals to perform EID-RLOC mapping under standardization include LISP Alternative Topology (LISP- ALT) [Dave, 2008] and LISP Map Server (LISP-MS). LISP-ALT uses existing protocols to build an alternative topology in order to manage the mapping. LISP-MS includes MAP-Servers that accept map-requests from ITRs and resolve the EID-to-RLOC map- ping using a database, which is filled with the authoritative EID-to-RLOC mappings provided by ETRs.

2.7.3.2 Internet Vastly Improved Plumbing

Internet Vastly Improved Plumbing (IvIP) architecture [Zhang et al., 2010b] is a core- edge split proposal implementing a map-and-encap approach. IvIP uses a fast-push mapping scheme, where all mapping information is kept on query database servers. Ingress tunnel routers query database servers to determine the correct egress tunnel router to which traffic must be routed. IvIP works for IPv4 and IPv6 and supports mo- bility through extensions. Nevertheless, the mapping requires real-time reachability monitoring.

2.7.3.3 A Practical Transit Mapping Service

A Practical Transit Mapping Service (APT) [Jen et al., 2007] is a proposal that aims to reduce the number of nodes that must be modified. APT introduces the encapsu- lation/decapsulation routers that maintain a reduced cache of mappings. Only the default mappers, new elements, have all the maps, and are used by the encapsulation routers when no match is found in their cache. The full mapping is obtained from a specific BGP instance, which introduces more overhead. In addition, as no reach- ability is preserved on the mapping, APT relies on external protocols (e.g. BGP) to detect failures on mappings. In comparison to LISP, APT has some advantages since no modifications are performed at the edge sites [Clevenger, 2010]. Nonetheless, the proposal has not been standardized and no specifications for incremental deployment have been produced.

2.7.3.4 Core Router-Integrated Overlay

Core Router-Integrated Overlay (CRIO) [Zhang et al., 2006] aims at mitigating the trade-off between path length and routing table size. CRIO decouples address hier- archy from physical topology and is suitable for global and VPN routing, as it relies on tunnels to forward data and on virtual prefixes to reduce routing tables size. CRIO

2.7 End-site Multihoming

supports mapping weights that establish the preference of entries over another in a multihoming context. CRIO in some cases does not provide the shortest path in the mapping. Mapping distribution relies on BGP and it has not reached standardization despite not requiring new hardware and supporting non continuous networks due to the aggregation of virtual prefixes [Clevenger, 2010].

2.7.3.5 IP with Virtual Link Extension

IP with Virtual Link Extension (IPvLX) [Templin, 2007; Clevenger, 2010] aims to allow IPv6 and IPv4 coexistence. IPvLX recommends to employ IPv6 addressees as iden- tifiers and IPv4 addresses as locators, although this is not a rigid rule. IPvLX uses DNS for mapping, thus requiring changes on DNS systems, and implements a ‘site- local’ resolution system to hold records of nodes that are more dynamic. IPvLX has not reached standardization and is more suitable to be employed with IPv4 to IPv6 transition solutions.

2.7.3.6 Tunneling Route Reduction Protocol

Tunneling Route Reduction Protocol (TRRP) [Clevenger, 2010; Herrin, 2007] relies on GRE tunnels to forward traffic. It uses DNS for mapping and introduces new records that establish how traffic is forwarded on IPv4 or IPv6 tunnels. As such, by having multiple entries in DNS with the respective preference, multihoming is supported, since a destination can be reached through several addresses. Nevertheless, routers must be modified to accommodate several records in the lookup operation. The TRRP specification describes an implementation plan that includes different phases; never- theless, no mobility support is stated.

2.7.3.7 Virtual Aggregation

Virtual Aggregation (ViAggre) [Ballani et al., 2009] is a proposal that also aims to re- duce the routing table size by aggregating routes into virtual prefixes and using such virtual networks inside the ISP. Virtual prefixes have no topological meaning and can be obtained by aggregating IPv4 addresses into 128 bit addresses. A router acting as an aggregation point only maintains routes for the virtual prefixes that it is aggregat- ing. When there is need to send packets to external routers, then MPLS tunnels are employed to avoid loops inside the ISP network. One advantage of ViAggre includes the possibility of incremental deployments as no changes are required in the routers

or network protocols, and it is transparent between ISPs [Clevenger, 2010]. Neverthe- less, ViAggre requires ISPs to use MPLS to enable encapsulation between aggregation points and introduces management overhead inside the ISP network, as configuration of aggregation points is needed. ViAggre has no public implementation available, al- though the authors published evaluation results from a real testbed.

Table 2.8: End-Site multihoming proposals with map and encapsulation, MH- Multihoming, OS-Operating System, Imp-Implementation.

Protocol MH Goals Strengths Flaws Imp

* R U L F OS LISP √ X √ X Flexible mapping Encapsulation overhead FreeBSDa

IvIP √ X √ √ Mobility support Scalability issues –

APT √ X √ √ Mobility support Scalability

issues.

–

CRIO √ X √ √ Policies support No Mobility

Support.

–

IPvLX √ √ X X For IPv4 to IPv6 transition Not Standardized. – TRRP √ X X X Works with existent protocols Requires changes in routers. – ViAggre √ √ X X Incremental deployments Requires MPLS. –

a_{[OpenLisp, 2013]} *_{Public implementation in network simulators are not available}

Mapping and encapsulation approaches, summarized in Table 2.8, have the advantage of facilitating deployment. LISP [Dave, 2008] is expected to decrease the size of routing tables in the core network when deployed. Others, such as IvIP [Zhang et al., 2010b] do not address mobility natively. APT [Jen et al., 2007] has deployment concerns, since it aims to reduce the number of nodes that require modification. In the same line of deployment concern, Core Router-Integrated Overlay (CRIO) [Zhang et al., 2006] does not require new hardware, as aggregation of prefixes is employed, but it does not provide the shortest path. Some proposals, like IPvLX [Templin, 2007] are tailored for IPv4-to-IPv6 transition, and as such, have limited multihoming sup-

2.8 Hybrid Multihoming

port. Tunneling Route Reduction Protocol (TRRP) [Clevenger, 2010] requires changes on DNS to allow the retrievement of multiple records, corresponding to the multiple addresses of an end-host. ViAggre [Ballani et al., 2009] is one of the proposals that enable ViAggre-compliant nodes to communicate with standard nodes (deployment concerns), but relies on MPLS to avoid loops.

2.8

Hybrid Multihoming

This section describes hybrid multihoming approaches in three distinct categories: First, content/service-centric approaches, which include solutions that focus on in- formation; Second, locator-identifier split approaches enable the separation of the dual-role (location and identification) in IP addresses; Third, new architectures and

routing-centric approaches that enable multihoming by providing scalable and effi-

cient routing mechanisms.