Locator/Id Split Protocol Improvement for High-Availability Environment - PDF

Please download to get full document.

View again

of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report

Paintings & Photography


Views: 5 | Pages: 8

Extension: PDF | Download: 0

Related documents
Locator/Id Split Protocol Improvement for High-Availability Environment Full-fledged LISP and VRRP simulation modules for OMNeT++ Vladimír Veselý, Ondřej Ryšavý Department of Information Systems Faculty
Locator/Id Split Protocol Improvement for High-Availability Environment Full-fledged LISP and VRRP simulation modules for OMNeT++ Vladimír Veselý, Ondřej Ryšavý Department of Information Systems Faculty of Information Technology, Brno University of Technology (FIT BUT) Brno, Czech Republic {ivesely, Abstract Locator/Id Split Protocol is a currently discussed alternative to deal with the traditional IP drawbacks (like cumbersome support of device mobility or more importantly default-free zone routing table growth due to the increased demand for multihoming and traffic engineering). This work outlines LISP and its properties for high-availability environments employing first-hop redundancy protocols. This paper also suggests LISP improvement for map-cache synchronization that should impact its routing performance. For this cause, two new simulation models (LISP and VRRP) are introduced that are behaviorally fully RFC compliant. Keywords-LISP; VRRP; map-cache synchronization; OMNeT++ I. INTRODUCTION The Automated Network Simulation and Analysis (ANSA) project running at our university is dedicated to developing the variety of simulation models compatible with RFC specifications or referential implementations. Subsequently, these tools allow a formal analysis of real networks and their configurations. They may be publicly used as the routing/switching baseline for further research initiatives, i.e., in simulations for proving (or disproving) certain aspects of technologies and/or related protocols. Locator/ID Split Protocol (LISP) emerged as one of the routing alternatives for Internet Protocol (IP) networks. LISP is the response to problems described in RFC 4984 [1] and RFC 6227 [2]. It should solve Internet architecture problems such as unscalable default-free zone (DFZ) routing, cumbersome mobility and prefix deaggregation caused by multihoming and ingress traffic engineering. IP address functionality is dual. It serves for identification ( which device is it? ) and localization ( where is the device? ) purposes. The main idea behind LISP is to remove this duality so that there are networks doing routing either based on locators (i.e., transit networks like DFZ) or identifiers (i.e., edge end networks). LISP accomplishes this by splitting the IP addresses into two distinct namespaces: a) Endpoint Identifier (EID) namespace (so called LISP site), where each device has unique address; b) Routing Locator (RLOC) namespace with addresses intended for localization. There is also a non-lisp namespace where direct LISP communication is (even intentionally) not supported. Apart from namespaces, there also exist: a) specialized routers (called tunnel router a.k.a. xtr) spanning between different namespaces; b) dedicated devices maintaining mapping system; and c) proxy routers allowing communication between LISP and non-lisp world. A LISP mapping system performs lookups to retrieve a set of RLOCs for a given EID. Tunnel routers between namespaces utilize these EID-to-RLOC mappings to perform map-and-encapsulation (see RFC 1955 [3]). The original (inner) header (with EIDs as addresses) is encapsulated by a new (outer) header (with RLOCs as addresses), which is appended when crossing borders from EID to RLOC namespace. Whenever a packet is crossing back from RLOC to EID namespace, the packet is decapsulated by stripping outer header off. Queries performing EID-to-RLOC mapping are datadriven. This behavior means that a new data transfer between LISP sites may require a mapping lookup, which causes that data dispatch is stopped until mapping is retrieved. This behavior is analogous to the domain-name system (DNS) protocol and allows LISP to operate decentralized database of EID-to-RLOC mappings. Replication of whole (potentially large-scale) database is unnecessary because mappings are accessed on-demand, just like as in DNS a host does not need to know complete domain database. Tunnel routers maintain map-cache of recently used mappings to improve performance of the system. LISP is being successfully deployed in enterprise networks, and one of its most beneficial use-cases is for datacenters networking. An important feature of any data-center is its ability to maintain high-availability of provided services. This goal is accomplished mainly with redundancy. In the case of the outage, service delivery is not affected because of redundant links, devices or power sources. Virtual Router Redundancy Protocol (VRRP) is among related protocols and technologies guaranteeing redundancy and helping to achieve high-availability. VRRP is widely adopted protocol providing redundancy of default-gateway (crucial L3 device that serves as exit/entry point to a given network). VRRP is IETF s response for 61 Cisco s proprietary Hot Standby Routing Protocol (HSRP) and Gateway Load Balancing Protocol (GLBP) delivering same goals. VRRP combines redundant first hop routers into virtual groups. One master router actively forwards clients traffic within each group, where others in the group are backing its functionality. Backup routers are periodically checking liveness of the master waiting ready to substitute it in case of failure. Switching to a new active router is transparent from the host s perspective thus no additional configuration or special software is needed. This paper introduces two new simulation modules, which create a part of the ANSA project and which extend the functionality of the INET framework in OMNeT++. Subsequently, they are employed as measurement tools supporting proposed LISP map-cache synchronization technique. This paper has the following structure. The next section covers a quick overview of existing simulation modules. Section III describes the design of relevant LISP and VRRP models. Section IV deals with a map-cache synchronization mechanism how synchronization works, how it is implemented and how it should aid devices to run LISP and VRRP simultaneously. Section V presents validation scenarios for outlined implementations and shows promising results backing up improvement s impact on LISP operation. The paper is summarized in Section VI together with unveiling of our plans. II. STATE OF THE ART This section outlines the current state of the art of available LISP and VRRP implementations for simulator environments. Limited LISP implementation was created [4] to support LISP MobileNode NAT traversal [5]. However, it is intended for outdated INET and OMNeT Previously, LISP map-cache performance have been evaluated employing high-level simulation that is not taking into account protocol implementation specifics [6]. We are not aware that any VRRP (or another first-hop redundancy protocol) implementation is supported by other major simulators like NS-2/3 or OPNET. According to our knowledge, OMNeT (discrete event simulator) and INET 2.4 (framework for wired networks simulation) do not support VRRP simulation modules at all. LISP is supported partially as the result of our previous research effort [7]. Thus, we have implemented LISP and VRRP modules by ourselves in order to have reliable components for subsequent research (i.e., evaluation of proposed improvements). III. IMPLEMENTATION A. LISP Theory of Operation LISP is being codified within IETF [8]. The main core and functionality is described in RFCs LISP supports both IPv4 and IPv6. Moreover, LISP is agnostic to address family thus it can seamlessly work with any upcoming network protocol. Transition mechanisms are part of the protocol standard. Hence, LISP supports communication with legacy non-lisp world. LISP places additional UDP header succeeded by LISP header between inner and outer header. LISP uses reserved port numbers 4341 for data traffic and 4342 for signalization. Basic components of the LISP architecture are Ingress Tunnel Router (ITR) and Egress Tunnel Router (ETR). Both are border devices between EID and RLOC space; the only difference is in which direction they operate. The single device could be either ITR-only or ETR-only or ITR and ETR at the same time (thus abbreviation xtr). ITR is the exit point from EID space to RLOC space, which encapsulates the original packet. This process may consist of querying mapping system followed by updating local map-cache, where EID-to-RLOC mapping pairs are stored for a limited time to reduce signalization overhead. ETR is the exit from RLOC space to EID space, which decapsulates packet. Outer header, auxiliary UDP, and LISP headers are stripped off. ETR is responsible for registering all LISP sites (their EID addresses) and by which RLOCs they are accessible. LISP mapping system consists of two components Map Resolver (MR) and Map Server (MS). The list below contains all LISP control messages responsible for mapping system signalization. They are without inner header just outer header, followed by UDP header (with source and destination ports set on 4342), followed by appropriate LISP message header. LISP Map-Register Each ETR announces LISP site(s) to the MS with this message. Each registration contains authentication data and the list of mappings and their properties. LISP Map-Notify UDP cannot guarantee message delivery. MS may optionally (when proper bit is set) confirm reception of LISP Map-Register with this message. LISP Map-Request ITR generates this request whenever it needs to discover current EID-to-RLOC mapping and sends a message to preconfigured MR. LISP Map-Reply This is a solicited response from the mapping system to the previous request and contains all RLOCs to a certain EID together with their attributes. MR processes ITR s LISP Map-Requests. Either MR responds with LISP Negative Map-Reply if queried address is from a non-lisp world (not EID), or LISP Map-Requests is delegated further into mapping system to appropriate MS. Every MS maintains mapping database of LISP sites that are advertised by LISP Map-Register messages. If MS receives LISP Map-Request then: a) either MS responds directly to querying ITR; or b) MS forwards request towards designated ETR that is registered to MS for target EID. xtrs perform RLOC probing (checking of non-local locator liveness) in order to always use current information. Each RLOC is accompanied by two attributes priority and weight. Priority (one byte long value in the range from 0 to 255) expresses each RLOC preference. The locator with the lowest priority is preferred for outer header address. Priority value 255 means that the locator must not be used for traffic forwarding. Incoming communication may be loadbalanced based on the weight value (in the range from 0 to 62 100) between multiple RLOCs sharing the same priority. Zero weight means that RLOC usage for load-balancing depends on ITR preferences. B. LISP Design of a Simulation Module Simulation model of LISP xtr, MR and MS functionality is currently implemented as LISPRouting compound module. It consists of five submodules that are depicted in Figure 1 and described in Table I below. LISPRouting exchanges messages with UDP, IPv4 networklayer, and IPv6 networklayer6 modules. Implementation is fully in compliance with RFC 6830 [9] and RFC 6833 [10]. Figure 1. LISPRouting module structure TABLE I. DESCRIPTION OF LISPROUTING SUBMODULES Name lispcore lispmapdatabase lispmapcache Lisp SiteDatabase lisp MsgLogger Description Module handles LISP control and data traffic. It independently combines functionality of ITR, ETR, MR and MS. This involves: encapsulation and decapsulation of data traffic; ETR site registration and MS site maintenance; ITR performing lookups; MR delegating requests. Each xtr maintains configuration of its LISP sites (i.e., which RLOCs belong to a given EID or which local interfaces are involved in LISP) that is used by control-plane during registration or for RLOC probing. Local LISP map-cache that is populated on demand by routing data traffic between LISP sites. Each record (EID-to-RLOC mapping) has its separate handling (i.e., expiration, refreshment, availability of RLOCs). MS s database that maintains LISP site registrations by ETRs. It contains site-specific information (e.g., shared key, statistics of registrars and most importantly known EID-to- RLOC mappings). This module records and collects statistics about LISP control plane operation, e.g. number, types, timestamps and length of messages. C. VRRP Theory of Operation VRRP specification is publicly available as RFC standard RFC 3768 [11] describes IPv4-only VRRPv2 and RFC 5798 [12] describes dual IPv4+IPv6 VRRPv3. VRRPv2 routers send control messages to multicast address VRRPv3 routers use ff02::12 for IPv6 communication. VRRP has its own reserved IP protocol number 112. Clustered redundant routers form a VRRP group identified by Virtual Router ID (VRID). Within the group, a single router (called Master) is elected based on announced priority (a number in the range from 1 to 255). Higher priority means superior willingness to become Master, zero priority causes router to abstain from being Master. In the case of equal priority, binary higher IP address serves as tie-breaker. VRRP election process is always preemptive (unlike to nonpreemptive HSRP or GLBP). Peemption means that the router with the highest priority always wins to be the Master no matter whether the group already have other Master elected. Only Master actively forwards traffic. Remaining routers (called Backups) are just listening and checking for Master s keep-alive messages. Hosts have configured virtual IP address as their defaultgateway. Only Master responds to ARP Requests for this IP. This IP address has assigned reserved MAC address 00:00:5e:00:01:$$ for VRRPv2 and 00:00:5e:00:02:$$ for IPv6 (where $$ is VRID). Whenever VRRP group changes to a new Master, ARP Gratuitous Reply is generated in order to rewrite association between the interface and reserved MAC in CAM table(s) of switch(es). This allows transparent changing of Masters for hosts during the outage. VRRP has only one type of control message VRRP Advertisement. If Master is not elected, then, VRRP routers exchange advertisements to determine which one is going to be a new Master. If Master is already elected, then, only Master is sending VRRP Advertisements to inform Backups that it is up and correctly running. VRRP Advertisement is generated whenever advertisement timer (AT) expires (by default every 1 second). If this interval is set to a lower value, then, Master s failure is detected faster but protocol overhead increases. Master down interval ( MDI ) resets with each reception of an advertisement message. Backup, which expires the MDI sooner, becomes a new Master. Value of MDI depends on priority of each VRRP router according to (1). The highest (best) priority Backup times out first (because of the lowest skew time) and thus takes over role as a new Master before others. skew time MDI = 3 AT priority 256 D. VRRP Design of Simulation Module VRRP version 2 is implemented as VRRPv2 compound module connected with networklayer. Module is a container for dynamically created instances of VRRPv2VirtualRouter during simulation startup. Each instance handles particular VRRP group operation on a given interface. Its structure is depicted in Figure 2, and a brief description of the functionality follows in Table II. Both modules together implement full-fledged VRRPv2 with the same finite-state machine (FSM) as in [11]. VRRP FSM s states Init, Backup and Master reflect VRRP router role and govern control message generation and processing. (1) 63 Name VRRPv2 VRRPv2 VirtualRouter Figure 2. VRRP modules structure TABLE II. DESCRIPTION OF VRRP MODULES Description Responsible for the creation of VRRPv2VirtualRouters according to the startup configuration and forwarding VRRP messages to/from them between appropriate gates. This module governs VRRP Advertisements processing, transition between states and directs ARP for a single VRRP group. IV. CONTRIBUTION Assume multiple redundant routers are acting as first hops in high-availability scenario. Those routers are simultaneously clustered into VRRP groups and act as LISP s xtrs they run LISP and VRRP at the same time. The performance of map-and-encap depends on the fact whether xtr s map-cache contains valid EID-to-RLOC mapping or not. Dispatched data traffic drives Map-cache record creation. If map-cache misses the mapping, then, a mapping system needs to be asked and initiating data traffic is meantime dropped. Packet dropping is a valid step as long as the mapping is not discovered because map-and-encap cannot occur without proper information. The rationale behind this behavior is the same as in the case of ARP throttling [13], where any triggering traffic should be discarded to protect control-plane processing and prevent superfluously recurrent mapping system queries. Each xtr has its own map-cache and its content may differ even within the same LISP site because each cache record may be initialized by different traffic. Hence, xtrs can easily experience severe packet drops and LISP control message storms due to the map-cache misses when Master change occurs within VRRP group. This problem is described as the one of LISP weak-points in [14] and theoretically investigated in [15]. The viable solution would be to provide map-cache content synchronization that should minimize map-cache misses upon failure. Inspired by that, we present our solution addressing this problem. We have decided to implement it as a technique maintaining synchronized map-caches within a predefined synchronization set (SS) of ITRs. Any solicited LISP Map- Reply triggers synchronization process among SS members. Each record in the map-cache is equipped with a time-tolive (TTL) parameter. TTL expresses for how long the record is considered to be valid and usable for map-and-encap. Mapcaches within SS must maintain the same TTL on shared records; otherwise a loss of synchronization might occur (on some ITRs, identical records could expire because of no demand by traffic). We have implemented two modes of synchronization: 1) Naïve The whole content of map-cache is transferred to SS. All mappings are then updated according to the new content and TTLs are reset. This approach works fine, but it obviously introduces significant transfer overheads; 2) Smart Only record that caused synchronization is transferred. Moreover, we bound this mode with following policy. When TTL expires, the ITR must check record usage during the last minute (one minute should be a period enough long to detect ongoing communication). If the mapping has not been used, then, it is removed from the cache. Otherwise, its state is refreshed by query followed by synchronization. Synchronization itself is done with the help of two new LISP messages: LISP CacheSync Message contains map-cache records that are being synchronized and authentication data protecting SS members from spoofed messages; LISP CacheSync Ack Because LISP leverages UDP, it cannot guarantee message delivery. However, we decided to employ the same principle as for LISP Map-Register and LISP Map-Notify. Hence, LISP CacheSync delivery may be optionally confirmed by echoing back LISP CacheSync Ack message. This approach guarantees that devices within SS could forward rerouted LISP data traffic without packet loss or interruption because they share the same content as ITR s map-cache of malfunctioned former VRRP Master. V. TESTING In this section, we provide information regarding validation of LISP and VRRP simulation models. This is necessary in order to build up reliability of used tools for subsequent evaluation of proposed map-cache synchronization technique. We have built exactly the same real network topologies as for simulations. We captured and analyzed (using transparent switchport analyzers and packet sniffers) relevant messages exchanged between devices for both LISP and VRRP functionality validation. We compared the results with the behavior
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks