Movatterモバイル変換

<?xml version='1.0' encoding='utf-8'?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"     ipr="trust200902" obsoletes="" updates="" submissionType="IETF"     xml:lang="en"  <!-- xml2rfc v2v3 conversion 2.23.0 -->  <front>    <title abbrev="LISP Introduction">An Architectural Introduction to the Locator/ID Separation Protocol (LISP)</title>    <seriesInfo    <author fullname="Albert Cabellos" initials="A." surname="Cabellos">      <organization>UPC-BarcelonaTech</organization>      <address>        <postal>          <street>c/ Jordi Girona 1-3</street>          <city>Barcelona</city>          <code>08034</code>          <region>Catalonia</region>          <country>Spain</country>        </postal>        <email>acabello@ac.upc.edu</email>      </address>    </author>    <author fullname="Damien Saucez (Ed.)" initials="D." surname="Saucez (Ed.)">      <organization>INRIA</organization>      <address>        <postal>          <street>2004 route des Lucioles BP 93</street>          <city>Sophia Antipolis Cedex</city>          <code>06902</code>          <country>France</country>        </postal>        <email>damien.saucez@inria.fr</email>      </address>    </author>    <date    <area>Routing Area</area>    <keyword>LISP</keyword>    <keyword>Architecture</keyword>    <abstract>      <t>This document describes the architecture of the Locator/ID SeparationProtocol (LISP), making it easier to read the rest of the LISPspecifications and providing a basis for discussion about the detailsof the LISP protocols. This document is used for introductory purposes,more details can be found in RFC6830, the protocol specification.</t>    </abstract>  </front>  <middle>    <section numbered="true" toc="default">      <name>Introduction</name>      <t>This document introduces the Locator/ID Separation Protocol (LISP)<xref format="default"/> architecture, its main operational mechanisms and its designrationale. Fundamentally, LISP is built following a well-knownarchitectural idea: decoupling the IP address overloaded semantics.Indeed and as pointed out by Noel Chiappa <xref format="default"/>, currently IP addresses bothidentify the topological location of a network attachment point aswell as the node's identity.  However, nodes and routing havefundamentally different requirements, routing systems require thataddresses are aggregatable and have topological meaning, while nodesrequire to be identified independently of their current location <xref format="default"/>.</t>      <t>LISP creates two separate namespaces, EIDs (End-host IDentifiers) andRLOCs (Routing LOCators), both aresyntactically identical to the current IPv4 and IPv6 addresses.  EIDsare used to uniquely identify nodes irrespective of their topologicallocation and are typically routed intra-domain. RLOCs are assignedtopologically to network attachment points and are typically routedinter-domain.  With LISP, the edge of the Internet (where the nodesare connected) and the core (where inter-domain routing occurs) can belogically separated and interconnected by LISP-capable routers.LISP also introduces a database, called theMapping System, to store and retrieve mappings between identity andlocation.  LISP-capable routers exchange packets over the Internetcore by encapsulating them to the appropriate location.</t>      <t>In summary:</t>      <ul spacing="normal">        <li>RLOCs have meaning only in the underlay network, that is the underlying core routing system.</li>        <li>EIDs have meaning only in the overlay network, which is the encapsulation relationship between LISP-capable routers.</li>        <li>The LISP edge maps EIDs to RLOCs</li>        <li>Within the underlay network, RLOCs have both locator and        identifier semantics</li>        <li>An EID within a LISP site carries both identifier and locator        semantics to other nodes within that site</li>        <li>An EID within a LISP site carries identifier and limited locator       semantics to nodes at other LISP sites (i.e., enough locator       information to tell that the EID is external to the site)</li>      </ul>      <t>The relationship described above is not unique to LISP but it is   common to other overlay technologies.</t>      <t>The initial motivation in the LISP effort is to be found in the   routing scalability problem <xref format="default"/>, where, if LISP were to be completely   deployed, the Internet core is populated with RLOCs while Traffic   Engineering mechanisms are pushed to the Mapping System.          In such scenario RLOCs are quasi-static (i.e., low churn), hence making the routing system   scalable <xref format="default"/>, while EIDs can roam anywhere with no churn to the   underlying routing system. <xref format="default"/> discusses the impact of LISP on the global routing          system during the transition period. However, the separation between location and identity   that LISP offers makes it suitable for use in additional   scenarios such as Traffic Engineering (TE), multihoming, and   mobility among others.</t>      <t>This document describes the LISP architecture and its main   operational mechanisms as well as its design rationale. It is important to note that thisdocument does not specify or complement the LISP protocol. Theinterested reader should refer to the main LISP specifications <xref format="default"/> and the complementary documents <xref format="default"/>, <xref format="default"/>, <xref format="default"/>, <xref format="default"/>, <xref format="default"/>,<xref format="default"/>, <xref format="default"/> for the protocol specifications along with theLISP deployment guidelines <xref format="default"/>.</t>    </section>    <section numbered="true" toc="default">      <name>Definition of Terms</name>      <dl spacing="normal">        <dt>Endpoint IDentifier (EID):</dt>        <dd> EIDs are addresses used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain.</dd>        <dt>Routing LOcator (RLOC):</dt>        <dd>RLOCs are addresses assigned topologically to network attachment points and typically routed inter-domain.</dd>        <dt>Ingress Tunnel Router (ITR):</dt>        <dd>A LISP-capable router that encapsulates packets from a LISP site towards the core network.</dd>        <dt>Egress Tunnel Router (ETR):</dt>        <dd>A LISP-capable router that decapsulates packets from the core of the network towards a LISP site.</dd>        <dt>xTR:</dt>        <dd>A router that implements both ITR and ETR functionalities.</dd>        <dt>Map-Request:</dt>        <dd>A LISP signaling message used to request an EID-to-RLOC mapping.</dd>        <dt>Map-Reply:</dt>        <dd>A LISP signaling message sent in response to a Map-Request that contains a resolved EID-to-RLOC mapping.</dd>        <dt>Map-Register:</dt>        <dd>A LISP signaling message used to register an EID-to-RLOC mapping.</dd>        <dt>Map-Notify:</dt>        <dd>A LISP signaling message sent in response of a Map-Register to acknowledge the correct reception of an EID-to-RLOC mapping.</dd>      </dl>      <t>This document describes the LISP architecture and does notintroduce any new term. The reader is referred to <xref format="default"/>, <xref format="default"/>, <xref format="default"/>, <xref format="default"/>, <xref format="default"/>, <xref format="default"/>,       <xref format="default"/>, <xref format="default"/>, <xref format="default"/> for the complete definition of terms.</t>    </section>    <section numbered="true" toc="default">      <name>LISP Architecture</name>      <t>This section presents the LISP architecture, it first details the      design principles of LISP and then it proceeds to describe its main aspects:      data-plane, control-plane, and internetworking mechanisms.</t>      <section numbered="true" toc="default">        <name>Design Principles</name>        <t>The LISP architecture is built on top of four basic design        principles:</t>        <ul spacing="normal">          <li>Locator/Identifier split: By decoupling the overloaded semantics of the            current IP addresses the Internet core can be assigned identity meaningful addresses and hence, can use aggregation to            scale. Devices are assigned with relatively opaque topologically meaningful addresses that            are independent of their topological location.</li>          <li>Overlay architecture: Overlays route packets over the current            Internet, allowing deployment of new protocols without changing the            current infrastructure hence, resulting into a low deployment            cost.</li>          <li>Decoupled data and control-plane: Separating the data-plane            from the control-plane allows them to scale independently and use            different architectural approaches. This is important given that            they typically have different requirements and allows for other data-planes to be added. While decoupled, data and control-plane      are not completely isolated because the LISP data-plane may      trigger control-plane activity.</li>          <li>Incremental deployability: This principle ensures that the protocol interoperates with the legacy Internet while providing some of the targeted benefits to early adopters.</li>        </ul>      </section>      <section numbered="true" toc="default">        <name>Overview of the Architecture</name>        <t>LISP splits architecturally the core from the edge of the Internet        by creating two separate namespaces: Endpoint Identifiers (EIDs) and        Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an Autonomous        System) that use EID addresses. EIDs are IPv4 or IPv6        addresses that uniquely identify communication end-hosts and are assigned and        configured by the same mechanisms that exist at the time of thiswriting. EIDs do not contain inter-domain topological information andbecause of this, EIDs are usually routable at the edge (within LISPsites) or in the non-LISP Internet; seefor discussion of LISP site internetworking with non-LISP sites and domains in the Internet.</t>        <t>LISP sites (at the edge of the Internet) are connected to the coreof the Internet by means of LISP-capable routers (e.g., borderrouters).  LISP sites are connected across the core of the Internetusing tunnels between the LISP-capable routers.When packets originated from a LISP site are flowing towards the core network, they ingress into an encapsulated tunnel via an Ingress Tunnel Router (ITR). When packets flow from the core network to a LISP site, they egress from an encapsulated tunnel to an Egress Tunnel Router (ETR).An xTR is a router which can perform both ITR and ETR operations. In this context ITRsencapsulate packets while ETRs decapsulate them, hence LISP operatesas an overlay on top of the current Internet core.</t>        <artwork name="" type="" align="left" alt=""><![CDATA[                       /-----------------\                 ---                       |     Mapping     |                  |                       .     System      |                  | Control                      -|                 |`,                | Plane                    ,' \-----------------/  .               |                   /                         |             ---   ,..,           -        _,....,,          |      ,..,    | /     `        ,'      ,-`        `',       |    /     `   |/        \ +-----+   ,'              `,  +-----+ /        \ ||  EID   |-| xTR |--/        RLOC     ,--| xTR |-|  EID   | | Data| Space  |-|     |--|       Space     |--|     |-| Space  | | Plane\        / +-----+  .                 /  +-----+ \        / | `.    .'            `.              ,'           `.    .'  |   `'-`                `.,        ,.'               `'-`   ---                          ``'''``  LISP Site (Edge)            Core              LISP Site (Edge)]]></artwork>        <t>With LISP, the core uses RLOCs, an RLOC is an IPv4 or IPv6        address assigned to an Internet-facing network interface of an ITR or        ETR. Typically RLOCs are numbered from topologically aggregatable        blocks assigned to a site at each point to which it attaches to the        global Internet, the topology is defined by the connectivity of        networks.</t>        <t>A database which is typically distributed, called the Mapping System,stores mappings between EIDs and RLOCs. Such mappings relate        the identity of the devices attached to LISP sites (EIDs) to the set        of RLOCs configured at the LISP-capable routers servicing the site.        Furthermore, the mappings also include traffic engineering policies        and can be configured to achieve multihoming and load balancing. The        LISP Mapping System is conceptually similar to the DNSwhere it is organized as a distributed multi-organization network database.With LISP, ETRs register mappings while ITRs retrieve them.</t>        <t>Finally, the LISP architecture emphasizes incremental deployment. Given that LISP represents an        overlay to the current Internet architecture, endhosts as well as        intra and inter-domain routers remain unchanged, and the only required        changes to the existing infrastructure are to routers connecting the        EID with the RLOC space. Additionally, LISP requires the deployment of        an independent Mapping System, such distributed database is a new        network entity.</t>        <t>The following describes a simplified packet flow sequence        between two nodes that are attached to LISP sites. Please note that typical LISP-capable routers are xTRs (both ITR and ETR). Client HostA        wants to send a packet to server HostB.</t>  <artwork name="" type="" align="left" alt=""><![CDATA[                         /----------------\                         |     Mapping    |                         |     System     |                        .|                |-                       ` \----------------/ `.                     ,`                       \                    /                          `.                  ,'         _,..-..,,           ',                 /         -`         `-,          \               .'        ,'              \          `,               `        '                 \           '           +-----+     |                   | RLOC_B1+-----+    HostA  |     |    |        RLOC         |-------|     |  HostB    EID_A--|ITR_A|----|        Space        |       |ETR_B|--EID_B           |     | RLOC_A1                  |-------|     |           +-----+     |                   | RLOC_B2+-----+                        ,                 /                         \               /                          `',         ,-`                             ``''-''``]]></artwork>        <ol spacing="normal" type="1">          <li>HostA retrieves the EID_B of HostB, typically querying the DNS and obtaining an A or AAAA record.            Then it generates an IP packet as in the Internet, the packet            has source address EID_A and destination address EID_B.</li>          <li>The packet is routed towards ITR_A in the LISP site using            standard intra-domain mechanisms.</li>          <li>ITR_A upon receiving the packet queries the Mapping System to            retrieve the locator of ETR_B that is servicing HostB's EID_B. In order            to do so it uses a LISP control message called Map-Request, the            message contains EID_B as the lookup key. In turn it receives            another LISP control message called Map-Reply, the message            contains two locators: RLOC_B1 and RLOC_B2 along with traffic            engineering policies: priority and weight per locator. Note that a Map-Reply can contain more locators if needed.   ITR_A also stores the mapping in a local cache to speed-up   forwarding of subsequent packets.</li>          <li>ITR_A encapsulates the packet towards RLOC_B1 (chosen according            to the priorities/weights specified in the mapping). The packet contains two            IP headers, the outer header has RLOC_A1 as source and RLOC_B1 as            destination, the inner original header has EID_A as source and EID_B as            destination. Furthermore ITR_A adds a LISP header, more details            about LISP encapsulation can be found in <xref format="default"/>.</li>          <li>The encapsulated packet is forwarded by the Internet core as a            normal IP packet, making the EID invisible from the Internet core.</li>          <li>Upon reception of the encapsulated packet by ETR_B, it            decapsulates the packet and forwards it to HostB.</li>        </ol>      </section>      <section numbered="true" toc="default">        <name>Data-Plane</name>        <t>This section provides a high-level description of the LISP data-plane,which is specified in detail in <xref format="default"/>. The LISP data-plane is responsible for        encapsulating and decapsulating data packets and caching the        appropriate forwarding state. It includes two main entities, the ITR        and the ETR, both are LISP capable routers that connect the EID withthe RLOC space (ITR) and vice versa (ETR). </t>        <section anchor="encapsulation" numbered="true" toc="default">          <name>LISP Encapsulation</name>          <t>ITRs encapsulate data packets towards ETRs. LISP data packets are          encapsulated using UDP (port 4341), the source port is usually selected by the ITR using a 5-tuple hash of the inner header (so to be consistent in case of multi-path solutions such as ECMP <xref format="default"/>) and ignored on reception.  LISP data packets are often encapsulated in UDP packets that  include a zero checksum <xref format="default"/> <xref format="default"/> that is not verified  when it is received, because LISP data packets typically include  an inner transport protocol header with a non-zero checksum. By  omitting the additional outer UDP encapsulation checksum, xTRs  can forward packets more efficiently. If LISP data packets are  encapsulated in UDP packets with non-zero checksums, the outer  UDP checksums are verified when the UDP packets are received, as  part of normal UDP processing.</t>          <t>LISP-encapsulated packets also include a LISP header (after the          UDP header and before the original IP header). The LISP header is prepended by ITRs and striped by          ETRs. It carries reachability information (see more details in <xref format="default"/>) and the Instance ID  field.  The Instance ID field is used to distinguish traffic to/from  different tenant address spaces at the LISP site and that may use  overlapped but logically separated EID addressing.</t>          <t>Overall, LISP works on 4 headers, the inner header the source constructed, and the 3 headers a LISP encapsulator prepends ("outer" to "inner"):</t>          <ol spacing="normal" type="1">            <li>Outer IP header containing RLOCs as source and destination              addresses. This header is originated by ITRs and stripped by              ETRs.</li>            <li>UDP header (port 4341) with zero checksum. This header is              originated by ITRs and stripped by ETRs.</li>            <li>LISP header that contains various forwarding-plane features (such as reachability) and an              Instance ID field. This header is originated by ITRs and              stripped by ETRs.</li>            <li>Inner IP header containing EIDs as source and destination              addresses. This header is created by the source end-host and              is left unchanged by LISP data plane processing on the ITR and ETR.</li>          </ol>          <t>Finally, in some scenarios Re-encapsulating and/or Recursivetunnels are useful to choose a specified path in the underlay network, for instance to avoid congestion or failure.Re-encapsulating tunnels are consecutive LISP tunnels and occur whena decapsulator (an ETR action) removes a LISP header and then acts as an encapsultor (an ITR action) to prependanother one.  On the other hand, Recursive tunnels are nested tunnelsand are implemented by using multiple LISP encapsulations on a packet. Such functions are implemented by Reencapsulating TunnelRouters (RTRs). An RTR can be thought of as a router that first acts as an ETR by decapsulating packets and then as an ITR by encapsulating them towards another locator, more information can be found at <xref format="default"/>.</t>        </section>        <section numbered="true" toc="default">          <name>LISP Forwarding State</name>          <t>In the LISP architecture, ITRs keep just enough information to route   traffic flowing through them. Meaning that, ITRs retrieve from the LISP   Mapping System mappings between EID-prefixes (blocks of EIDs) and RLOCs that are used   to encapsulate packets.  Such mappings are stored in a local cache called the Map-Cache for subsequent packets addressed to the same EID   prefix.  Note that, in case of overlapping EID-prefixes, following a   single request, the ITR may receive a set of mappings, covering the   requested EID-prefix and all more-specifics <xreftarget="RFC6830" Mappings include a (Time-to-Live) TTL (set by the ETR).   More details about the Map-Cache management can be found in <xref format="default"/>.          </t>        </section>      </section>      <section numbered="true" toc="default">        <name>Control-Plane</name>        <t>The LISP control-plane, specified in <xref format="default"/>, provides a standardinterface to register and request mappings.  The LISPMapping System is a database that stores suchmappings.  The following first describes the mappings, then thestandard interface to the Mapping System, and finally its architecture.</t>        <section numbered="true" toc="default">          <name>LISP Mappings</name>          <t>Each mapping includes the bindings between EID prefix(es) and          set of RLOCs as well as traffic engineering policies, in the form of          priorities and weights for the RLOCs. Priorities allow the ETR to          configure active/backup policies while weights are used to          load-balance traffic among the RLOCs (on a per-flow basis).</t>          <t>Typical mappings in LISP bind EIDs in the form of IP prefixes witha set of RLOCs, also in the form of IPs.  IPv4 and IPv6 addresses areencoded using the appropriate Address Family Identifier (AFI)<xref format="default"/>. However LISP can also support more general address encodingby means of the ongoing effort around the LISP Canonical Address Format (LCAF)<xref format="default"/>.</t>          <t>With such a general syntax for address encoding in place, LISP          aims to provide flexibility to current and future applications. For          instance LCAFs could support          MAC addresses, geo-coordinates, ASCII names and application specific          data.</t>        </section>        <section numbered="true" toc="default">          <name>Mapping System Interface</name>          <t>LISP defines a standard interface between data and control          planes. The interface is specified in <xref format="default"/> and          defines two entities:</t>          <dl spacing="normal">            <dt>Map-Server:</dt>            <dd>A network infrastructure component              that learns mappings from ETRs and publishes them into the LISP              Mapping System. Typically Map-Servers are not authoritative to              reply to queries and hence, they forward them to the ETR.              However they can also operate in proxy-mode, where the ETRs              delegate replying to queries to Map-Servers. This setup is              useful when the ETR has limited resources (i.e., CPU or power).</dd>            <dt>Map-Resolver:</dt>            <dd>A network infrastructure component              that interfaces ITRs with the Mapping System by proxying queries              and in some cases responses. </dd>          </dl>          <t> The interface defines four LISP control messages which are          sent as UDP datagrams (port 4342):</t>          <dl spacing="normal">            <dt>Map-Register:</dt>            <dd>This message is used by ETRs to              register mappings in the Mapping System and it is authenticated              using a shared key between the ETR and the Map-Server.</dd>            <dt>Map-Notify:</dt>            <dd>When requested by the ETR, this message is sent by theMap-Server in response to a Map-Register to acknowledge the correctreception of the mapping and convey the latest Map-Server state on theEID to RLOC mapping. In some cases a Map-Notify can be sent to the previous RLOCs when an EID is registered by a new set of RLOCs.</dd>            <dt>Map-Request:</dt>            <dd>This message is used by ITRs or              Map-Resolvers to resolve the mapping of a given EID.</dd>            <dt>Map-Reply:</dt>            <dd>This message is sent by Map-Servers or ETRs in response toa Map-Request and contains the resolved mapping.  Please note that aMap-Reply may contain a negative reply if, for example, the queried EID is not partof the LISP EID space.  In such cases the ITR typically forwards thetraffic natively (non encapsulated) to the public Internet, thisbehavior is defined to support incremental deployment of LISP.</dd>          </dl>        </section>        <section numbered="true" toc="default">          <name>Mapping System</name>          <t>LISP architecturally decouples control and data-plane by means of          a standard interface. This interface glues the data-plane, routers          responsible for forwarding data-packets, with the LISP Mapping          System, a database responsible for storing          mappings.</t>          <t>With this separation in place the data and control-plane can use          different architectures if needed and scale independently.          Typically the data-plane is optimized to route packets according to          hierarchical IP addresses. However the control-plane may have          different requirements, for instance and by taking advantage of the          LCAFs, the Mapping System may be used to store          non-hierarchical keys (such as MAC addresses),          requiring different architectural approaches for scalability.          Another important difference between the LISP control and          data-planes is that, and as a result of the local mapping cache          available at ITR, the Mapping System does not need to operate at          line-rate.</t>          <t>      Many of the existing mechanisms to create distributed systems have been explored and considered for the Mapping System architecture:           graph-based databases in the form of LISP+ALT <xref format="default"/>, hierarchical databases in the form of LISP-DDT          <xref format="default"/>, monolithic databases in the form          of LISP-NERD <xref format="default"/>, flat databases          in the form of LISP-DHT <xref format="default"/>,<xref format="default"/> and, a multicast-based database <xref format="default"/>. Furthermore it is worth noting that, in some          scenarios such as private deployments, the Mapping System can operate as logically centralized.          In such cases it is typically composed of a single Map-Server/Map-Resolver.</t>          <t>The following focuses on the two mapping systems that have          been implemented and deployed (LISP-ALT and LISP+DDT).</t>          <section numbered="true" toc="default">            <name>LISP+ALT</name>            <t>  The LISP Alternative Topology (LISP+ALT) <xref format="default"/> was the firstMapping System proposed, developed and deployed on the LISP pilotnetwork.  It is based on a distributed BGP overlay participated byMap-Servers and Map-Resolvers. The nodes connect to their peersthrough static tunnels. Each Map-Server involved in the ALT topologyadvertises the EID-prefixes registered by the serviced ETRs, makingthe EID routable on the ALT topology.            </t>            <t>When an ITR needs a mapping it sends a Map-Request to a Map-Resolverthat, using the ALT topology, forwards the Map-Request towards theMap-Server responsible for the mapping. Upon reception the Map-Serverforwards the request to the ETR that in turn, replies directly to theITR using the native Internet core.</t>          </section>          <section numbered="true" toc="default">            <name>LISP-DDT</name>            <t>  LISP-DDT <xref format="default"/> is conceptually similar to the DNS, ahierarchical directory whose internal structure mirrors thehierarchical nature of the EID address space.  The DDT hierarchy iscomposed of DDT nodes forming a tree structure, the leafs of the treeare Map-Servers.  On top of the structure there is the DDT root node<xref format="default"/>, which is a particular instance of a DDT node and thatmatches the entire address space.  As in the case of DNS, DDT supportsmultiple redundant DDT nodes and/or DDT roots. Finally, Map-Resolversare the clients of the DDT hierarchy and can query either the DDT rootand/or other DDT nodes.            </t>            <artwork name="" type="" align="left" alt=""><![CDATA[                        /---------\                        |         |                        | DDT Root|                        |   /0    |                      ,.\---------/-,                  ,-'`       |       `'.,               -'`           |           `-           /-------\     /-------\    /-------\           |  DDT  |     |  DDT  |    |  DDT  |           | Node  |     | Node  |    | Note  |  ...           |  0/8  |     |  1/8  |    |  2/8  |           \-------/     \-------/    \-------/         _.                _.            . -..,,,_       -`                -`              \        ````''--+------------+     +------------+   +------------+ +------------+| Map-Server |     | Map-Server |   | Map-Server | | Map-Server || EID-prefix1|     | EID-prefix2|   | EID-prefix3| | EID-prefix4|+------------+     +------------+   +------------+ +------------+ the the prefixes and the structure depicted should only considered as an            <t>The DDT structure does not actually index EID-prefixes but            eXtended EID-prefixes (XEID). An XEID-prefix is just the            concatenation of the following fields (from most significant bit            to less significant bit): Database-ID, Instance ID, Address Family            Identifier and the actual EID-prefix. The Database-ID is provided            for possible future requirements of higher levels in the hierarchy            and to enable the creation of multiple and separate database            trees.</t>            <t>In order to resolve a query LISP-DDT operates in a similar way to theDNS but only supports iterative lookups. DDT clients (usually Map-Resolvers)            generate Map-Requests to the DDT root node. In response they            receive a newly introduced LISP-control message: a Map-Referral. A            Map-Referral provides the list of RLOCs of the set of DDT nodes            matching a configured XEID delegation. That is, the information            contained in the Map-Referral points to the child of the queried            DDT node that has more specific information about the queried            XEID-prefix. This process is repeated until the DDT client walks            the tree structure (downwards) and discovers the Map-Server            servicing the queried XEID. At this point the client sends a            Map-Request and receives a Map-Reply containing the mappings. It            is important to note that DDT clients can also cache the            information contained in Map-Referrals, that is, they cache the            DDT structure. This is used to reduce the mapping retrieving format="default"/>.</t>            <t>The DDT Mapping System relies on manual configuration. That is            Map- Resolvers are manually configured with the set of available            DDT root nodes while DDT nodes are manually configured with the            appropriate XEID delegations. Configuration changes in the DDT            nodes are only required when the tree structure changes itself,            but it doesn't depend on EID dynamics (RLOC allocation or traffic            engineering policy changes).</t>          </section>        </section>      </section>      <section numbered="true"        <name>Internetworking Mechanisms</name>        <t>EIDs are typically identical to either IPv4 or IPv6 addresses and        they are stored in the LISP Mapping System, however they are usually not        announced in the Internet global routing system. As a result LISP        requires an internetworking mechanism to allow LISP sites to speak        with non-LISP sites and vice versa. LISP internetworking mechanisms are        specified in <xref format="default"/>.</t>        <t>LISP defines two entities to provide internetworking:</t>        <dl spacing="normal">          <dt>Proxy Ingress Tunnel Router (PITR):</dt>          <dd>PITRs provide            connectivity from the legacy Internet to LISP sites. PITRs            announce in the global routing system blocks of EID prefixes            (aggregating when possible) to attract traffic. For each incoming packet from a source not in a LISP site (a non-EID),the PITR LISP-encapsulates it towards the RLOC(s) of            the appropriate LISP site. The impact of PITRs in the routing            table size of the Default-Free Zone (DFZ) is, in the worst-case, similar to the case            in which LISP is not deployed. EID-prefixes will be aggregated            as much as possible both by the PITR and by the global routing system.</dd>          <dt>Proxy Egress Tunnel Router (PETR):</dt>          <dd>PETRs provide            connectivity from LISP sites to the legacy Internet. In some scenarios, LISP sites may be unable to send encapsulatedpackets with a local EID address as a source to the legacy Internet. For instance when Unicast Reverse Path            Forwarding (uRPF) is used by Provider Edge routers, or when an            intermediate network between a LISP site and a non-LISP site does            not support the desired version of IP (IPv4 or IPv6). In both            cases the PETR  overcomes such limitations by            encapsulating packets over the network. There is no specified provision for the distribution of PETR RLOC addresses to the ITRs.</dd>        </dl>        <t>Additionally, LISP also defines mechanisms to operate with private EIDs <xref format="default"/> by means of LISP-NAT <xref format="default"/>. In this casethe xTR replaces a private EID source address with a routable one. At the time of this writing, work is ongoing to define NAT-traversal capabilities, that is xTRs behind a NAT using non-routable RLOCs.</t>        <t>PITRs, PETRs and, LISP-NAT enable incremental deployment of LISP,by providing significant flexibility in the placement of the boundaries between theLISP and non-LISP portions of the network, and making it easy to change those boundaries over time.</t>      </section>    </section>    <section numbered="true" toc="default">      <name>LISP Operational Mechanisms</name>      <t>This section details the main operational mechanisms defined in      LISP.</t>      <section anchor="management" numbered="true" toc="default">        <name>Cache Management</name>        <t>LISP's decoupled control and data-plane, where mappings are          stored in the control-plane and used for forwarding in the data          plane, requires a local cache in ITRs to reduce signaling          overhead (Map-Request/Map-Reply) and increase forwarding speed. The          local cache available at the ITRs, called Map-Cache, is used by the          router to LISP-encapsulate packets. The Map-Cache is indexed by          (Instance ID, EID-prefix) and contains basically the set          of RLOCs with the associated traffic engineering policies (priorities and          weights).</t>        <t>The Map-Cache, as any other cache, requires cache coherence          mechanisms to maintain up-to-date information. LISP defines three          main mechanisms for cache coherence:</t>        <dl spacing="normal">          <dt>Time-To-Live (TTL):</dt>          <dd>Each mapping contains a TTL set by the ETR, uponexpiration of the TTL the ITR can't use the mapping until it is refreshed bysending a new Map-Request.  Typical values for TTL defined by LISPare 24 hours.</dd>          <dt>Solicit-Map-Request (SMR):</dt>          <dd>SMR is an explicit              mechanism to update mapping information. In particular a special              type of Map-Request can be sent on demand by ETRs to request refreshing             a mapping. Upon reception of a SMR              message, the ITR must refresh the bindings by sending a              Map-Request to the Mapping System. Further uses of SMRs are documented in <xref format="default"/>.</dd>          <dt>Map-Versioning:</dt>          <dd>This optional mechanism piggybacks in the LISP header of data-packets the            version number of the mappings used by an xTR.  This way, when an xTR receives            a LISP-encapsulated packet from a remote xTR, it can check whether its own            Map-Cache or the one of the remote xTR is outdated.  If its Map-Cache is            outdated, it sends a Map-Request for the remote EID so to obtain the newest            mappings.  On the contrary, if it detects that the remote xTR Map-Cache is            outdated, it sends a SMR to notify it that a new mapping is available.</dd>        </dl>        <t>Finally it is worth noting that in some cases an entry in themap-cache can be proactively refreshed using the mechanisms describedin the section below.</t>      </section>      <section anchor="reachability" numbered="true" toc="default">        <name>RLOC Reachability</name>        <t>In most cases LISP operates with a pull-based Mapping System (e.g., DDT),this results in an edge to edge pull architecture. In such scenario the networkstate is stored in the control-plane while the data-plane pulls it on demand.This has consequences concerning the propagation of xTRs reachability/livenessinformation since pull architectures require explicit mechanisms to propagate this information.As a result LISP defines a set of mechanisms to inform ITRs and PITRS about the reachability of the cached RLOCs:</t> Status Bits is a passive technique, the LSB field is carried by data-packetsin the LISP header and can be set by a ETRs to specify which RLOCs of the ETR site areup/down. This information        can be used by the ITRs as a hint about the reachability to perform        additional checks. Also note that LSB does not provide path        reachability status, only hints on the status of is also a passive technique, that can only operate        effectively when data flows bi-directionally between two communicating xTRs.        Basically, an ITR piggybacks a random number (called nonce) in LISP        data packets, if the path and the probed locator are up, the ETR will        piggyback the same random number on the next data-packet, if this is        not the case the ITR can set the locator as unreachable. When traffic        flow is unidirectional or when the ETR receiving the traffic is not        the same as the ITR that transmits it back, additional mechanisms are is an active probing algorithm where ITRs sendprobes to specific locators, this effectively probes both the locatorand the path. In particular this is done by sending a Map-Request(with certain flags activated) on the data-plane (RLOC space) andwaiting in return a Map-Reply, also sent on the data-plane. The active        nature of RLOC-probing provides an effective mechanism to determine        reachability and, in case of failure, switching to a different        locator. Furthermore the mechanism also provides useful RTT        estimates of the delay of the path that can be used by other network        <t>It is worth noting that RLOC probing and Echo-nonce can work together.Specifically if a nonce is not echoed, an ITR could RLOC-probe todetermine if the path is up when it cannot tell the difference between afailed bidirectional path or the return path is not used (aunidirectional path).</t>        <t>Additionally, LISP also recommends inferring reachability of        locators by using information provided by the underlay, in        particular:</t> LISP underlay -the current Internet- uses the        ICMP protocol to signal unreachability (among other things). LISP can        take advantage of this and the reception of a ICMP Network Unreachable        or ICMP Host Unreachable message can be seen as a hint that a locator        might be unreachable, this should lead to perform additional BGP and IBGP carry reachability information,        LISP-capable routers that have access to underlay routing information        can use it to determine if a given locator or path are      </section>      <section numbered="true" toc="default">        <name>ETR Synchronization</name>        <t>All the ETRs that are authoritative to a particular EID-prefix mustannounce the same mapping to the requesters, this means that ETRs must beaware of the status of the RLOCs of the remaining ETRs. This is known asETR synchronization.</t>        <t>At the time of this writing LISP does not specify a mechanism to achieve ETR  synchronization. Although many well-known techniques could be applied to solve this issue  it is still under research, as a result operators must  rely on coherent manual configuration</t>      </section>      <section numbered="true" toc="default">        <name>MTU Handling</name>        <t>Since LISP encapsulates packets it requires dealing with packets that exceed the MTU of the path between the ITR                and the ETR. Specifically LISP defines two mechanisms:</t>        <dl spacing="normal">          <dt>Stateless:</dt>          <dd>With this mechanism the effective MTU is assumed from theITR's perspective. If a payload packet is too big for the effective MTU, andcan be fragmented, the payload packet is fragmented on the ITR, such thatreassembly is performed at the destination host.</dd>          <dt>Stateful:</dt>          <dd>With this mechanism ITRs keep track of the MTU of thepaths towards the destination locators by parsing the ICMP Too Bigpackets sent by intermediate routers. ITRs will send ICMP Too Big messages to inform the sources about the effective MTU.Additionally ITRs can use mechanisms such as PMTUD <xref format="default"/> or PLPMTUD <xref format="default"/> to keep track of the MTU towards the locators.</dd>        </dl>        <t>In both cases if the packet cannot be fragmented (IPv4 with DF=1 or IPv6) then the ITR drops                it and replies with a ICMP Too Big message to the source.</t>      </section>    </section>    <section numbered="true" toc="default">      <name>Mobility</name>      <t>The separation between locators and identifiers in LISP is suitablefor traffic engineering purpose where LISP sites can change their attachmentpoints to the Internet (i.e., RLOCs) without impacting endpoints or theInternet core. In this context, the border routers operate the xTRfunctionality and endpoints are not aware of the existence of LISP. This functionality is similar to Network Mobility <xref format="default"/>. However,this mode of operation does not allow seamless mobility of endpoints betweendifferent LISP sites as the EID address might not be routable in a visitedsite.  Nevertheless, LISP can be used to enable seamless IP mobility when LISPis directly implemented in the endpoint or when the endpoint roams to an attached xTR.Each endpoint is then an xTR and the EID address is the one presented to the network stack used by applicationswhile the RLOC is the address gathered from the network when it is visited. This functionality is similar to Mobile IP (<xref format="default"/> and <xref format="default"/>).</t>      <t>Whenever the device changes of RLOC, the xTR updates the RLOC of its          local mapping and registers it to its Map-Server, typically with a low TTL value (1min). To avoid the need of a          home gateway, the ITR also indicates the RLOC change to all remote devices          that have ongoing communications with the device that moved.  The          combination of both methods ensures the scalability of the system as          signaling is strictly limited the Map-Server and to hosts with which          communications are ongoing. In the mobility case the EID-prefix can be as small as a full /32 or /128 (IPv4 or IPv6 respectively) depending on the specific use-case (e.g., subnet mobility vs single VM/Mobile node mobility).</t>      <t>The decoupled identity and location provided by LISP allows it to operate with other layer 2 and layer 3 mobility solutions.</t>    </section>    <section numbered="true" toc="default">      <name>Multicast</name>      <t>LISP also supports transporting IP multicast packets sent from the EIDspace, the operational changes required to the multicast protocols aredocumented in <xref format="default"/>.</t>      <t>In such scenarios, LISP may create multicast state both at the coreand at the sites (both source and receiver).  When signaling is usedto create multicast state at the sites, LISP routers unicast encapsulatePIM Join/Prune messages from receiver to source sites.  At the core,ETRs build a new PIM Join/Prune message addressed to the RLOC of theITR servicing the source.  An simplified sequence is shown below</t>      <ol spacing="normal" type="1">        <li>An end-host willing to join a multicast channel sends an IGMPreport. Multicast PIM routers at the LISP site propagate PIMJoin/Prune messages (S-EID, G) towards the ETR.</li>        <li>The join message flows to the ETR, upon reception the ETR builds two join messages,            the first one unicast LISP-encapsulates the original join message towards the RLOC of the            ITR servicing the source. This message creates (S-EID, G) multicast state at the source site.            The second join message contains as destination address the RLOC of the ITR            servicing the source (S-RLOC, G) and creates multicast state at the core.</li>        <li>Multicast data packets originated by the source (S-EID, G) flow from the source        to the ITR. The ITR LISP-encapsulates the multicast packets, the outter header includes its own RLOC        as the source (S-RLOC) and the original multicast group address (G) as the destination. Please        note that multicast group address are logical and are not resolved by the mapping system. Then        the multicast packet is transmitted through the core towards the receiving ETRs that decapsulates        the packets and sends them using the receiver's site multicast state.</li>      </ol>      <t>Please note that the inner and outer multicast addresses are in general different,unless in specific cases where the underlay provider implements a tight control on the overlay. LISP specifications already support all PIM modes <xref format="default"/>. Additionally,LISP can support as well non-PIM mechanisms in order to maintain multicast state.</t>    </section>    <section numbered="true" toc="default">      <name>Use Cases</name>      <section numbered="true" toc="default">        <name>Traffic Engineering</name>        <t> A LISP site can strictly impose via which ETRs the          traffic must enter the the LISP site network even though the path followed to reach the          ETR is not under the control of the LISP site.  This fine control is          implemented with the mappings.  When a remote site is willing to send          traffic to a LISP site, it retrieves the mapping associated to the          destination EID via the mapping system.  The mapping is sent directly by an          authoritative ETR of the EID and is not altered by any intermediate network.  </t>        <t>A mapping associates a list of RLOCs to an EID prefix.  Each RLOC          corresponds to an interface of an ETR (or set of ETRs) that is able to correctly forward          packets to EIDs in the prefix.  Each RLOC is tagged with a priority and a          weight in the mapping.  The priority is used to indicates which RLOCs          should be preferred to send packets (the least preferred ones being          provided for backup purpose).  The weight permits to balance the load          between the RLOCs with the same priority, proportionally to the weight          value.</t>        <t>As mappings are directly issued by the authoritative ETR of the EID and are not altered          while transmitted to the remote site, it offers highly flexible incoming          inter-domain traffic engineering with even the possibility for a site to support a different mappingpolicy for each remote site.          routing policies.</t>      </section>      <section numbered="true" toc="default">        <name>LISP for IPv6 Co-existence</name>        <t>LISP encapsulations allows to transport packets using EIDs from a given          address family (e.g., IPv6) with packets from other address families (e.g., IPv4). The absence of correlation between          the address family of RLOCs and EIDs makes LISP a candidate to allow, e.g., IPv6 to be deployed when all of the corenetwork may not have IPv6 enabled.</t>        <t>For example, two IPv6-only data centers could be interconnected via the          legacy IPv4 Internet. If their border routers are LISP capable, sending          packets between the data center is done without any form of translation as          the native IPv6 packets (in the EID space) will be LISP encapsulated and          transmitted over the IPv4 legacy Internet by the mean of IPv4 RLOCs.</t>      </section>      <section numbered="true" toc="default">        <name>LISP for Virtual Private Networks</name>        <t>It is common to operate several virtual networks over the same          physical infrastructure. In such virtual private networks, it is essential to distinguish which virtual          network a packet belongs and tags or labels are used for that purpose.          When using LISP, the distinction can be made with the Instance ID field.  When an          ITR encapsulates a packet from a particular virtual network (e.g., known          via the VRF or VLAN), it tags the encapsulated packet with the Instance ID          corresponding to the virtual network of the packet.  When an ETR receives a          packet tagged with an Instance ID it uses the Instance ID to determine how          to treat the packet. </t>        <t>The main usage of LISP for virtual private networks does not introduceadditional requirements on the underlying network, as long as it is  running IP.</t>      </section>      <section numbered="true" toc="default">        <name>LISP for Virtual Machine Mobility in Data Centers</name>        <t>A way to enable seamless virtual machine mobility in data center is to          conceive the datacenter backbone as the RLOC space and the subnet          where servers are hosted as forming the EID space. A LISP router is placed          at the border between the backbone and each subnet. When a virtual          machine is moved to another subnet, it can keep (temporarily) the address it had before the move so to continue without a transport layer connection reset. When an xTR detects a source address received on a subnet to be an address not assigned to the subnet, it registers the address to the Mapping System.</t>        <t>To inform the other LISP routers that the machine moved and where, and thento avoid detours via the initial subnetwork, mechanisms such as theSolicit-Map-Request messages are used.</t>      </section>    </section>    <section numbered="true" toc="default">      <name>Security Considerations</name>      <t>This section describes the security considerations associated to the LISP protocol.</t>      <t>While in a push   mapping system, the state necessary to forward packets is learned   independently of the traffic itself, with a pull architecture, the   system becomes reactive and data-plane events (e.g., the arrival of a   packet for an unknown destination) may trigger control-plane events.   This on-demand learning of mappings provides many advantages as   discussed above but may also affect the way security is enforced.</t>      <t>Usually, the data-plane is implemented in the fast path of routers to        provide high performance forwarding capabilities while the control-plane        features are implemented in the slow path to offer high flexibility and a        performance gap of several order of magnitude can be observed between the slow        and the fast paths.  As a consequence, the way data-plane events are notified        to the control-plane must be thought carefully so to not overload the slow path        and rate limiting should be used as specified in <xref format="default"/>.</t>      <t>Care must also be taken so to not overload the mapping system (i.e., the        control plane infrastructure) as the operations to be performed by the mapping        system may be more complex than those on the data-plane, for that reason        <xref format="default"/> recommends to rate limit the sending of messages to the          mapping system.</t>      <t>To improve resiliency and reduce the overall number of messages exchanged,        LISP offers the possibility to leak information, such as reachabilty        of locators, directly into data plane packets.  In environments that are not        fully trusted, control information gleaned from data-plane packets should be        verified before using them.</t>      <t>  Mappings are the centrepiece of LISP and all precautions must be taken to   avoid them to be manipulated or misused by malicious entities.  Using   trustable Map-Servers that strictly respect and the lightweight   authentication mechanism proposed by LISP-Sec <xref format="default"/> reduces   the risk of attacks to the mapping integrity.  In more critical   environments, secure measures may be needed.  The way security is   implemented for a given mapping system strongly depends on the architecture   of the mapping system itself and the threat model assumed for the   deployment. Thus, the mapping system security has to be discussed in therelevant documents proposing the mapping system architecture.      </t>      <t>As with any other tunneling mechanism, middleboxes on the path between an ITR (or PITR) and an ETR (or PETR)  must implement mechanisms to strip the LISP encapsulation to correctlyinspect the content of LISP encapsulated packets. </t>      <t>    Like other map-and-encap mechanisms, LISP enables triangular routing (i.e.,packets of a flow cross different border routers depending on their direction).This means that intermediate boxes may have incomplete view on the traffic theyinspect or manipulate. Moreover, LISP-encapsulated packets are routedbased on the outer IP address (i.e., the RLOC), and can bedelivered to an ETR that is not responsible of the destination EID of thepacket or even to a network element that is not an ETR. The mitigationconsists in applying appropriate filtering techniques on the network elementsthat can potentially receive un-expected LISP-encapsulated packets</t>      <t>More details about security implications of LISP are discussed in        <xref format="default"/>.      </t>    </section>    <section numbered="true" toc="default">      <name>IANA Considerations</name>      <t>This memo includes no request to IANA.</t>    </section>    <section anchor="Acknowledgements" numbered="true" toc="default">      <name>Acknowledgements</name>      <t>This document was initiated by Noel Chiappa and much of the corephilosophy came from him.  The authors acknowledge the important contributionshe has made to this work and thank him for his past efforts.</t>      <t>The authors would also like to thank Dino Farinacci, Fabio Maino,Luigi Iannone,  Sharon Barkai, Isidoros Kouvelas, Christian Cassar,Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Bonica,Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, David Black as well as every people acknowledged in <xref format="default"/>.</t>    </section>  </middle>  <back>    <references>      <name>References</name>      <references>        <name>Normative References</name>        <reference anchor="I-D.ietf-lisp-ddt">          <front>            <title>LISP Delegated Database Tree</title>            <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-ddt-09"/>            <author initials="V" surname="Fuller" fullname="Vince Fuller">              <organization/>            </author>            <author initials="D" surname="Lewis" fullname="Darrel Lewis">              <organization/>            </author>            <author initials="V" surname="Ermagan" fullname="Vina Ermagan">              <organization/>            </author>            <author initials="A" surname="Jain" fullname="Amit Jain">              <organization/>            </author>            <author initials="A" surname="Smirnov" fullname="Anton Smirnov">              <organization/>            </author>            <date month="January" day="18" year="2017"/>            <abstract>              <t>This document describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs).  It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes.  Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated.</t>            </abstract>          </front>        </reference>        <reference anchor="I-D.ietf-lisp-lcaf">          <front>            <title>LISP Canonical Address Format (LCAF)</title>            <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-lcaf-22"/>            <author initials="D" surname="Farinacci" fullname="Dino Farinacci">              <organization/>            </author>            <author initials="D" surname="Meyer" fullname="David Meyer">              <organization/>            </author>            <author initials="J" surname="Snijders" fullname="Job Snijders">              <organization/>            </author>            <date month="November" day="28" year="2016"/>            <abstract>              <t>This document defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System.</t>            </abstract>          </front>        </reference>        <reference anchor="I-D.ietf-lisp-threats">          <front>            <title>LISP Threats Analysis</title>            <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-threats-15"/>            <author initials="D" surname="Saucez" fullname="Damien Saucez">              <organization/>            </author>            <author initials="L" surname="Iannone" fullname="Luigi Iannone">              <organization/>            </author>            <author initials="O" surname="Bonaventure" fullname="Olivier Bonaventure">              <organization/>            </author>            <date month="January" day="29" year="2016"/>            <abstract>              <t>This document provides a threat analysis of the Locator/Identifier Separation Protocol (LISP).</t>            </abstract>          </front>        </reference>        <reference anchor="I-D.ietf-lisp-sec">          <front>            <title>LISP-Security (LISP-SEC)</title>            <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-sec-18"/>            <author initials="F" surname="Maino" fullname="Fabio Maino">              <organization/>            </author>            <author initials="V" surname="Ermagan" fullname="Vina Ermagan">              <organization/>            </author>            <author initials="A" surname="Cabellos-Aparicio" fullname="Albert Cabellos-Aparicio">              <organization/>            </author>            <author initials="D" surname="Saucez" fullname="Damien Saucez">              <organization/>            </author>            <date month="June" day="2" year="2019"/>            <abstract>              <t>This memo specifies LISP-SEC, a set of security mechanisms that provides origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process.  LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages.</t>            </abstract>          </front>        </reference>      </references>      <references>        <name>Informative References</name>        <reference anchor="Jakab">          <front>            <title>LISP-TREE: A DNS Hierarchy to Support the LISP Mapping          System, IEEE Journal on Selected Areas in Communications, vol. 28,          no. 8, pp. 1332-1343</title>            <author initials="L." surname="Jakab"/>            <author initials="A." surname="Cabellos"/>            <author initials="D." surname="Saucez"/>            <author initials="O." surname="Bonaventure"/>            <date month="October" year="2010"/>          </front>        </reference>        <reference anchor="Mathy">          <front>            <title>LISP-DHT: Towards a DHT to map identifiers onto locators.  The ACM ReArch, Re-Architecting the Internet. Madrid (Spain)</title>            <author initials="L." surname="Mathy"/>            <author initials="L." surname="Iannone"/>            <author initials="O." surname="Bonaventure"/>            <date month="December" year="2008"/>          </front>        </reference>        <reference anchor="I-D.cheng-lisp-shdht">          <front>            <title>LISP Single-Hop DHT Mapping Overlay</title>            <seriesInfo name="Internet-Draft" value="draft-cheng-lisp-shdht-04"/>            <author fullname="Li Cheng" initials="L" surname="Cheng">              <organization/>            </author>            <author fullname="Jun Wang" initials="J" surname="Wang">              <organization/>            </author>            <date day="15" month="July" year="2013"/>            <abstract>              <t>This draft specifies the LISP Single-Hop Distributed Hash Table            Mapping Database (LISP-SHDHT), a distributed mapping database            which consists of a set of SHDHT Nodes to provide mappings from            LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). EID            namespace is dynamically distributed among SHDHT Nodes based on            DHT Hash algorithm. Each SHDHT Node is configured with one or more            hash spaces which contain multiple EID-prefixes along with RLOCs            of corresponding Map Servers.</t>            </abstract>          </front>        </reference>        <reference anchor="I-D.curran-lisp-emacs">          <front>            <title>EID Mappings Multicast Across Cooperating Systems for LISP</title>            <seriesInfo name="Internet-Draft" value="draft-curran-lisp-emacs-00"/>            <author fullname="S. Brim" initials="S" surname="Brim">              <organization/>            </author>            <author fullname="Dino Farinacci" initials="D" surname="Farinacci">              <organization/>            </author>            <author fullname="Dave Meyer" initials="D" surname="Meyer">              <organization/>            </author>            <author fullname="J Curran" initials="J" surname="Curran">              <organization/>            </author>            <date day="9" month="November" year="2007"/>            <abstract>              <t> One of the potential problems with the "map-and-encapsulate"   approaches to routing architecture is that there is a significant   chance of packets being dropped while a mapping is being retrieved.   Some approaches pre-load ingress tunnel routers with at least part of   the mapping database.  Some approaches try to solve this by providing intermediate "default" routers which have a great deal more knowledge   than a typical ingress tunnel router.  This document proposes a   scheme which does not drop packets yet does not require a great deal   of knowledge in any router.  However, there are still some issues   that need to be worked out.</t>            </abstract>          </front>        </reference>        <reference anchor="DDT-ROOT">          <front>            <title>http://ddt-root.org/</title>            <author surname="LISP DDT ROOT"/>            <date month="August" year="2013"/>          </front>        </reference>        <reference anchor="Quoitin">          <front>            <title>"Evaluating the Benefits of the Locator/Identifier Separation" in Proceedings of 2Nd ACM/IEEE International Workshop on Mobility in the Evolving Internet Architecture</title>            <author initials="B." surname="Quoitin"/>            <author initials="L." surname="Iannone"/>            <author initials="C." surname="Launois"/>            <author initials="O." surname="Bonaventure"/>            <date year="2007"/>          </front>        </reference>      </references>    </references>    <section numbered="true" toc="default">      <name>A Brief History of Location/Identity Separation</name>      <t>The LISP architecture for separation of location and identity resulted from      the discussions of this topic at the Amsterdam IAB Routing and      Addressing Workshop, which took place in October 2006 <xref format="default"/>.</t>      <t>A small group of like-minded personnel spontaneously formed immediately after thatworkshop, to work on an idea that came out of informal discussions atthe workshop and on various mailing lists.  The firstInternet-Draft on LISP appeared in January, 2007.</t>      <t>Trial implementations started at that time, with initial trial      deployments underway since June 2007; the results of early experience      have been fed back into the design in a continuous, ongoing process      over several years.  LISP at this point represents a moderately      mature system, having undergone a long organic series of changes and      updates.</t>      <t>LISP transitioned from an IRTF activity to an IETF WG in March 2009,      and after numerous revisions, the basic specifications moved to      becoming RFCs at the start of 2013 (although work to expand and      improve it, and find new uses for it, continues, and undoubtly will      for a long time to come).</t>      <section numbered="true" toc="default">        <name>Old LISP Models</name>        <t>LISP, as initially conceived, had a number of potential operating      modes, named 'models'.  Although they are no used anymore, one      occasionally sees mention of them, so they are briefly described      here.</t>        <dl spacing="normal">          <dt>LISP 1:</dt>          <dd>EIDs all appear in the normal routing and forwarding            tables of the network (i.e. they are 'routable');this property is            used to 'bootstrap' operation, by using this to load EID-&gt;RLOC            mappings.  Packets were sent with the EID as the destination in            the outer wrapper; when an ETR saw such a packet, it would send a            Map-Reply to the source ITR, giving the full mapping.</dd>          <dt>LISP 1.5:</dt>          <dd>Similar to LISP 1, but the routability of EIDs happens            on a separate network.</dd>          <dt>LISP 2:</dt>          <dd>EIDs are not routable; EID-&gt;RLOC mappings are available            from the DNS.</dd>          <dt>LISP 3:</dt>          <dd>EIDs are not routable; and have to be looked up in in a            new EID-&gt;RLOC mapping database (in the initial concept, a system            using Distributed Hash Tables).  Two variants were possible: a            'push' system, in which all mappings were distributed to all ITRs,            and a 'pull' system in which ITRs load the mappings they need, as            needed.</dd>        </dl>      </section>    </section>  </back></rfc>