An Architectural Analysis of the LISP Location-Identity Separation System

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2012-07-09
Replaced by draft-ietf-lisp-architecture
Stream (None)
Intended RFC status (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
LISP Working Group                                            N. Chiappa
Internet-Draft                              Yorktown Museum of Asian Art
Intended status: Informational                              July 9, 2012
Expires: January 10, 2013

                 An Architectural Analysis of the LISP
                  Location-Identity Separation System


   LISP upgrades the architecture of the IPvN internetworking system by
   separating location and identity, current intermingled in IPvN
   addresses.  This is a change which has been identified by the IRTF as
   a critically necessary evolutionary architectural step for the
   Internet.  In LISP, nodes have both a 'locator' (a name which says
   _where_ in the network's connectivity structure the node is) and an
   'identifier' (a name which serves only to provide a persistent handle
   for the node).  A node may have more than one locator, or its locator
   may change over time (e.g. if the node is mobile), but it keeps the
   same identifier.

   One of the chief novelties of LISP, compared to other proposals for
   the separation of location and identity, is its approach to deploying
   this upgrade.  In general, it is comparatively easy to conceive of
   new network designs, but much harder to devise approaches which will
   actually get deployed throughout the global network.  LISP aims to
   achieve the near-ubiquitous deployment necessary for maximum
   exploitation of an architectural upgrade by i) minimizing the amount
   of change needed (existing hosts and routers can operate unmodified);
   and ii) by providing significant benefits to early adopters.

   This document gives additional architectural insight into LISP, and
   analyzes a number of aspects of LISP from a long-term perspective.

   NOTE: This is an initial rough draft, a much better version will be
   out shortly.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 10, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Architectual Frameworks
     2.1.  'Double-Ended' Approach
     2.2.  Critical State
     2.3.  Need for a Mapping System
     2.4.  Piggybacking of Control on User Data
   3.  Namespaces
     3.1.  LISP EIDs
       3.1.1.  Residual Location Functionality in EIDs
     3.2.  RLOCs
     3.3.  Overlapping Uses of Existing Namespaces
     3.4.  LCAFs
   4.  Fault Discovery/Handling
   5.  Scalability
     5.1.  Demand Loading of Mappings
     5.2.  Caching of Mappings
     5.3.  Amount of State
     5.4.  Scalability of The Indexing Subsystem
   6.  Security
     6.1.  Basic Philosophy
     6.2.  Design Guidance
       6.2.1.  Security Mechanism Complexity
     6.3.  Security Overview
     6.4.  Securing Mappings
     6.5.  Securing the xTRs
   7.  Robustness
   8.  Optimization
   9.  Open Issues
   10. Additional Material
   11. Acknowledgments
   12. IANA Considerations
   13. Security Considerations
   14. References
     14.1. Normative References
     14.2. Informative References
   Appendix A.  RefComment
   Appendix B.  Glossary/Definition of Terms
   Appendix C.  Other Appendices

1.  Introduction

   This document begins by introducing some high-level architectural
   frameworks which have proven useful for thinking about the LISP
   location-identity separation system.  It then discusses some
Show full document text