The Experts below are selected from a list of 12300 Experts worldwide ranked by ideXlab platform

Dino Farinacci - One of the best experts on this subject based on the ideXlab platform.

  • Lisp Traffic Engineering Use-Cases
    2017
    Co-Authors: Dino Farinacci, Michael Kowal, Parantap Lahiri
    Abstract:

    This document describes how Lisp reencapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no Lisp protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these Lisp mechanisms can span intra-domain, inter-domain, or combination of both.

  • Lisp canonical address format lcaf
    RFC, 2017
    Co-Authors: Job Snijders, David E Meyer, Dino Farinacci
    Abstract:

    This document defines a canonical address format encoding used in Locator/ID Separation Protocol (Lisp) control messages and in the encoding of lookup keys for the Lisp Mapping Database System.

  • Lisp mobile node
    2016
    Co-Authors: Chris White, Darrel Lewis, David E Meyer, Dino Farinacci
    Abstract:

    This document describes how a lightweight version of Lisp's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The Lisp Mobile Node design described in this document uses standard Lisp functionality to provide scalable mobility for Lisp mobile nodes.

  • Lisp: a southbound SDN protocol?
    IEEE Communications Magazine, 2015
    Co-Authors: Alberto Rodriguez-natal, Dino Farinacci, Darrel Lewis, Vina Ermagan, Fabio Maino, Marc Portoles-comeras, Albert Cabellos-aparicio
    Abstract:

    The Locator/ID Separation Protocol (Lisp) splits current IP addresses overlapping semantics of identity and location into two separate namespaces. Since its inception the protocol has gained considerable attention from both industry and academia, motivating several new use cases to be proposed. Despite its inherent control-data decoupling and the abstraction and flexibility it introduces into the network, little has been said about the role of Lisp on the SDN paradigm. In this article we try to fill that gap and analyze if Lisp can be used for SDN. The article presents a systematic analysis of the relevant SDN requirements and how such requirements can be fulfilled by the Lisp architecture and components. This results in a set of benefits (e.g. incremental deployment, scalability, flexibility, interoperability, and inter-domain support) and drawbacks (e.g. extra headers and some initial delay) of using Lisp for SDN. In order to validate the analysis, we have built and tested a prototype using the Lispmob open-source implementation.

  • interworking between locator id separation protocol Lisp and non Lisp sites
    RFC, 2013
    Co-Authors: Dino Farinacci, Darrel Lewis, David Meyer, Vince Fuller
    Abstract:

    This document describes techniques for allowing sites running the Locator/ID Separation Protocol (Lisp) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running Lisp. A fundamental property of Lisp-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- Lisp-speaking sites to exchange traffic with Lisp-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the Lisp Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate Lisp Ingress Tunnel Router (ITR) for non-Lisp- speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to Lisp ITRs and Lisp Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a Lisp ITR cannot send packets to non-Lisp sites without encapsulation. This document defines an Experimental Protocol for the Internet community.

Olivier Bonaventure - One of the best experts on this subject based on the ideXlab platform.

  • implementing the locator id separation protocol design and experience
    Computer Networks, 2011
    Co-Authors: Luigi Iannone, Damien Saucez, Olivier Bonaventure
    Abstract:

    During the last few years, the network research community and the industry have been working on the design of an alternate Internet Routing Architecture aiming at solving the issues arising in the current architecture. It is widely accepted that applying a Locator/ID Separation paradigm would result in a more scalable and flexible architecture. As the name suggests, in Locator/ID Separation the identification (ID) and the localization (locator) of end-points is separated, while the link between the ID and the Locator(s) is ensured by what is called the mapping system. In this paper, we present OpenLisp, an open source implementation of Lisp (Locator/ID Separation Protocol). Lisp is a Locator/Identifier separation solution based on the map-and-encap approach, which has the merit of being incrementally deployable, hence, falling in the category of dirty-slate approaches. OpenLisp is not a merely implementation of the Lisp specifications; it also defines the mapping sockets, a socket-based abstraction making the Data Plane and the Control Plane implementations independent. The evaluation provided in this paper shows the limited impact on the protocol stack performance compared to traditional non-encapsulated traffic.

  • Lisp tree a dns hierarchy to support the Lisp mapping system
    IEEE Journal on Selected Areas in Communications, 2010
    Co-Authors: Loránd Jakab, Florin Coras, Albert Cabellosaparicio, Damien Saucez, Olivier Bonaventure
    Abstract:

    During the last years, some operators have expressed concerns about the continued growth of the BGP routing tables in the default-free zone. Several proposed solutions for this issue are centered around the idea of separating the network node's identifier from its topological location. Among the existing proposals, the Locator/ID Separation Protocol (Lisp) has seen important development and implementation effort. Lisp relies on a mapping system to provide bindings between locators and identifiers. The mapping system is a critical protocol component, and its design is still an open issue. In this paper we present a new mapping system: Lisp-TREE. It is based on DNS and has a similar hierarchical topology: blocks of identifiers are assigned to the levels of the hierarchy by following the current IP address allocation policies. We also present measurement-driven simulations of mapping systems' performance, assuming a deployment of Lisp in the current Internet.

Darrel Lewis - One of the best experts on this subject based on the ideXlab platform.

  • Lisp map server reliable transport
    2019
    Co-Authors: Christian Cassar, Darrel Lewis, Isidor Kouvelas, Jesus Arango, Johnson Leong
    Abstract:

    The communication between Lisp ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map- Server. New use cases for Lisp have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow- control and endpoint liveness detection.

  • Lisp mobile node
    2016
    Co-Authors: Chris White, Darrel Lewis, David E Meyer, Dino Farinacci
    Abstract:

    This document describes how a lightweight version of Lisp's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The Lisp Mobile Node design described in this document uses standard Lisp functionality to provide scalable mobility for Lisp mobile nodes.

  • Lisp: a southbound SDN protocol?
    IEEE Communications Magazine, 2015
    Co-Authors: Alberto Rodriguez-natal, Dino Farinacci, Darrel Lewis, Vina Ermagan, Fabio Maino, Marc Portoles-comeras, Albert Cabellos-aparicio
    Abstract:

    The Locator/ID Separation Protocol (Lisp) splits current IP addresses overlapping semantics of identity and location into two separate namespaces. Since its inception the protocol has gained considerable attention from both industry and academia, motivating several new use cases to be proposed. Despite its inherent control-data decoupling and the abstraction and flexibility it introduces into the network, little has been said about the role of Lisp on the SDN paradigm. In this article we try to fill that gap and analyze if Lisp can be used for SDN. The article presents a systematic analysis of the relevant SDN requirements and how such requirements can be fulfilled by the Lisp architecture and components. This results in a set of benefits (e.g. incremental deployment, scalability, flexibility, interoperability, and inter-domain support) and drawbacks (e.g. extra headers and some initial delay) of using Lisp for SDN. In order to validate the analysis, we have built and tested a prototype using the Lispmob open-source implementation.

  • locator identifier separation protocol Lisp network element deployment considerations
    RFC, 2014
    Co-Authors: Florin Coras, Loránd Jakab, Darrel Lewis, Albert Cabellosaparicio, Jordi Domingopascual
    Abstract:

    This document is a snapshot of different Locator/Identifier Separation Protocol (Lisp) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the Lisp working group as of Summer 2013. Lisp deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding.

  • interworking between locator id separation protocol Lisp and non Lisp sites
    RFC, 2013
    Co-Authors: Dino Farinacci, Darrel Lewis, David Meyer, Vince Fuller
    Abstract:

    This document describes techniques for allowing sites running the Locator/ID Separation Protocol (Lisp) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running Lisp. A fundamental property of Lisp-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- Lisp-speaking sites to exchange traffic with Lisp-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the Lisp Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate Lisp Ingress Tunnel Router (ITR) for non-Lisp- speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to Lisp ITRs and Lisp Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a Lisp ITR cannot send packets to non-Lisp sites without encapsulation. This document defines an Experimental Protocol for the Internet community.

Gerard Assayag - One of the best experts on this subject based on the ideXlab platform.

Vince Fuller - One of the best experts on this subject based on the ideXlab platform.

  • interworking between locator id separation protocol Lisp and non Lisp sites
    RFC, 2013
    Co-Authors: Dino Farinacci, Darrel Lewis, David Meyer, Vince Fuller
    Abstract:

    This document describes techniques for allowing sites running the Locator/ID Separation Protocol (Lisp) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running Lisp. A fundamental property of Lisp-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- Lisp-speaking sites to exchange traffic with Lisp-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the Lisp Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate Lisp Ingress Tunnel Router (ITR) for non-Lisp- speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to Lisp ITRs and Lisp Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a Lisp ITR cannot send packets to non-Lisp sites without encapsulation. This document defines an Experimental Protocol for the Internet community.

  • locator id separation protocol Lisp map server interface
    RFC, 2013
    Co-Authors: Vince Fuller, Dino Farinacci
    Abstract:

    This document describes the Mapping Service for the Locator/ID Separation Protocol (Lisp), implemented by two new types of Lisp- speaking devices -- the Lisp Map-Resolver and Lisp Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases. By using this service interface and communicating with Map-Resolvers and Map-Servers, Lisp Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the Lisp infrastructure, connect directly to Lisp-capable Internet end sites, and comprise the bulk of Lisp-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying Lisp. This document defines an Experimental Protocol for the Internet community.

  • the locator id separation protocol Lisp
    RFC, 2013
    Co-Authors: Darrel Lewis, Dino Farinacci, Vince Fuller, Dave Meyer
    Abstract:

    This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (Lisp) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few Lisp-capable sites. Design and development of Lisp was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community.

  • Lisp delegated database tree
    2012
    Co-Authors: Amit Jain, Darrel Lewis, Vince Fuller, Vina Ermagan
    Abstract:

    This draft 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.

  • Lisp map server
    2009
    Co-Authors: Vince Fuller, Dino Farinacci
    Abstract:

    This draft describes the Lisp Map-Server (Lisp-MS), a computing system which provides a simple Lisp protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of Lisp protocol elements. The purpose of the Map-Server is to simplify the implementation and operation of Lisp Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the Lisp infrastructure and which connect directly to Lisp-capable Internet end sites.