Identifier-locator control daemon
draft-herbert-idlocd-00

Versions: 00                                                            
INTERNET-DRAFT                                                T. Herbert
Intended Status: Experimental                                 Quantonium
Expires: April 2018

                                                         October 4, 2017


                   Identifier-locator control daemon
                        draft-herbert-idlocd-00


Abstract

   Identifier-locator protocols rely on a mapping system that is able to
   map identifiers to locators. Such a mapping system is a type of
   key/value store. This draft proposes a design and implementation for
   an Identifier-Locator control daemon (idlocd). The intent is to
   provide an open source implementation that would be a basis for
   experimentation, development, and eventual deployment of identifier-
   locator solutions at large scale.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

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




T. Herbert               Expires April 7, 2018                  [Page 1]


INTERNET DRAFT          draft-herbert-idlocd-00


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) 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 . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2 Identifier-locator characteristics . . . . . . . . . . . . . . .  3
     2.1 Encapsulation and non-encapsulation  . . . . . . . . . . . .  3
     2.2 Virtualization and non-virtualization  . . . . . . . . . . .  3
     2.3 Identifier/locator deployment modes  . . . . . . . . . . . .  4
     2.4 Cache management . . . . . . . . . . . . . . . . . . . . . .  5
   3 General architecture . . . . . . . . . . . . . . . . . . . . . .  6
     3.1 Mapping system . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1 Mapping management . . . . . . . . . . . . . . . . . . .  7
       3.1.2 Mapping system database  . . . . . . . . . . . . . . . .  7
     3.2 ilocd Manager  . . . . . . . . . . . . . . . . . . . . . . .  7
       3.2.1 Interface between idlocd manager and mapping systems . .  8
       3.2.2 Interface between ilocd and the dataplane  . . . . . . .  8
     3.3 ilocd dataplane  . . . . . . . . . . . . . . . . . . . . . .  9
   4  Implementation guidelines . . . . . . . . . . . . . . . . . . .  9
     4.1 General requirements . . . . . . . . . . . . . . . . . . . .  9
     4.2 Performance and scalability  . . . . . . . . . . . . . . . .  9
   5  Security Considerations . . . . . . . . . . . . . . . . . . . . 10
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1  Normative References  . . . . . . . . . . . . . . . . . . . 11
     7.2  Informative References  . . . . . . . . . . . . . . . . . . 11
   8 Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11














T. Herbert               Expires April 7, 2018                  [Page 2]


INTERNET DRAFT          draft-herbert-idlocd-00


1 Introduction

   This document proposes creation of an open source project to define
   and implement a control daemon for identifier-locator protocols. A
   goal of this is to provide a platform to facilitate development of a
   mapping system and protocols for the IDEAS effort in IETF.

   The identifier-locator daemon, or "idlocd", will be designed and
   implemented in the same spirit as open source routing daemons like
   gated, BIRD, or Quagga. It should be able to support different
   mapping systems and different identifier-locator protocols.

2 Identifier-locator characteristics

   This section provides some background on different characteristics of
   identifier-locator protocols that are relevant to a control plane
   implementation.

2.1 Encapsulation and non-encapsulation

   Identifier-locator protocols can be divided into two classes: those
   based on encapsulation and those that are not.

   Encapsulation based protocols include VXLAN and LISP. In this model,
   the identifiers and locators are IP addresses (IPv4 or IPv6). In the
   dataplane, a packet considered to be addressed by an identifier is
   encapsulated with another IP header whose destination address is a
   locator.

   Identifier-locator protocols that do not use encapsulation include
   ILA and ILNP. In this case, an IP address is split into a locator and
   identifier component. In the dataplane, the locator portion of the
   address (which is routable) is set to the appropriate locator.

   idloc should be able to gracefully serve both types assuming the
   details of the particular protocol are properly abstracted. The
   mapping system will need to contain the correctly sized identifier
   and locators for the protocol in use, and it may also provide
   additional information for the dataplane (e.g. protocol specific
   options for encapsulation).

2.2 Virtualization and non-virtualization

   Network virtualization is typically implemented using overlay
   networks. In network virtualization, virtual addresses are mapped to
   physical addresses for delivery. This is isomorphic to the mapping of
   identifiers to locators, and hence a common mechanism can be used in
   idlocd. Network virtualization includes the concept of different



T. Herbert               Expires April 7, 2018                  [Page 3]


INTERNET DRAFT          draft-herbert-idlocd-00


   virtual networks that are represented by a Virtual Network Identifier
   (VNI). To accommodate that in idlocd, the identifier key used to look
   up a mapping in an idlocd database could be a concatenation of a VNI
   and a virtual address.

2.3 Identifier/locator deployment modes

   Identifier-locator mapping can be performed at different parts of the
   network.

   The figure below illustrates three possible network deployments:

        +------+                                                +------+
        | Host +--+                                        +----| Host |
        |      |  |                                       (')   |      |
        +------+  |               ............           (   )  +------+
                   |  +--------+  .         .  +--------+ (_)
                   |  | idloc  |--.         .--| idloc  |  |
                   +--|fwcache |  . L3      .  | router |--+
                      +--------+  . network .  +--------|
                      /           .         .
                     /            .         .  +-------++-------+
         +------+   /             .         .  | idloc || Host  |
         | Host +--+              .         .--| host  ||       |
         |      |                 ...........  +-------++-------+
         +------+

   Note that "hosts" in this diagram could be a virtual or physical
   endpoints. This includes servers, UEs, tasks, VMs, or anything else
   that can be addressed.

   The idloc deployment variants are:

     o Router

       This is a node that performs identifier-locator mapping within
       the network. These are nodes that forward packets based on a
       mapping and perform encapsulation or address translation for the
       associated identifier-locator protocol. A group of idloc routers
       synchronize a shared database so that each router has the set of
       mappings for the domain they serve. The mapping database could be
       sharded across a set of routers so that each router maintains
       only the mappings for the shard it serves.

     o Fwcache (forwarding cache)

       This is similar to an idloc router in that it performs forwarding
       and encapsulation of an identifier-locator protocol, however the



T. Herbert               Expires April 7, 2018                  [Page 4]


INTERNET DRAFT          draft-herbert-idlocd-00


       mapping table it maintains is a cache. A protocol is used to
       query an idloc router to resolve mappings and populate the cache.
       The specifics of cache management are dependent of the mapping
       system, and similar to other types of cache resolution scenarios
       (neighbor discovery, ARP, DNS) there are a number of possible
       approaches.

     o Host

       This is an instance of identifier-locator mapping that runs
       directly on the host. The mapping system for this is most likely
       a cache (like in fwcache), but it's also possible to implement a
       router and participate in the idloc router protocols. Since an
       idloc host is integrated into the host stack, the implementation
       may include optimizations to leverage that. For instance, the
       result of a mapping look up for a connection might be done only
       once if the mapping information is cached in the connection
       context (the ILA implementation currently does this).

2.4 Cache management

       In identifier-locator protocols, a mapping cache may be populated
       by a "push" or a "pull" model. In the push model, changes to the
       mapping database are proactively pushed to nodes. A pub/sub model
       may be implemented to limit the announcement of changes only to
       those nodes that are interested. The pub/sub model is very good
       for communicating changes with low latency and limiting messages
       to interested parties, however it is stateful and could be
       difficult to scale.

       In the "pull" model, a node initiates a request for mapping data
       when it needs to send. The request can be explicit or implicit.

       In the explicit case, a node uses a request/response resolution
       protocol (similar to ARP). The target is an identifier that needs
       to be resolved to a locator, and the request is sent to a router
       that has access to the mapping table which contains the
       identifier.

       For the implicit case, a node sends a packet using a default
       locator that routes a packet to an idloc router. In addition to
       performing encapsulation or translation to forward the packet,
       the router may also send back a redirect message that contains
       the locator for the identifier that was used. Upon receiving the
       redirect message, a node may subsequently use the indicated
       locator to send to the associated identifier.

       The pull model is stateless and possibly more scalable than push



T. Herbert               Expires April 7, 2018                  [Page 5]


INTERNET DRAFT          draft-herbert-idlocd-00


       model, however latency of propagating changes may be greater. An
       implicit pull model requires fewer packets to be sent than an
       explicit one, however an implicit resolution protocol is harder
       to secure against message spoofing.

       Additional cache management may include expiration timeouts,
       eviction due to memory constraints, and LRU management of
       evictions.

       idlocd should be able to support the various caching models
       described above. A instance of a mapping system might be tightly
       coupled with the dataplane implementation of a protocol. For
       instance, to perform an explicit resolution, the mapping system
       may need a callback in the datapath for when a packet is sent to
       an unresolved identifier.

3 General architecture

       The stack of idlocd is:

       +---------------------------+ \
       |  Mapping management       | |
       +---------------------------+ | Mapping system
       |  Mapping system DB        | |
       +---------------------------+ /
                     |
       +---------------------------+
       |    ilocd manager          |
       +---------------------------+
                     |
       +---------------------------+ \
       | Dataplane interface       | |
       +---------------------------+ | Dataplane
       | Dataplane implementation  | |
       +---------------------------+ /

       There are three major layers in this design: the mapping system
       and the dataplane contain specific implementations of mapping
       systems and identifier-locator dataplanes. The ilocd manager is
       generalized to be the interface between the mapping system and
       dataplane.

3.1 Mapping system

       The mapping systems layer consists of different implementations
       or protocols. This design allows for experimentation and
       development for different mapping systems with different
       characteristics. This includes potential use of databases and



T. Herbert               Expires April 7, 2018                  [Page 6]


INTERNET DRAFT          draft-herbert-idlocd-00


       NoSQL databases (such as Redis and Casandra), routing protocols
       (BGP for instance), simple map files, or other variants. The
       specifics of each mapping system are contained in a software
       module, and an interface abstraction is use to provide mappings
       to the ilocd manager.

3.1.1 Mapping management

       This is the external interface into a mapping system. It is used
       to set identifier to locator mappings, remove them, and to query
       the database. The interfaces may be specific to the mapping
       system or ilocd may provide them an generic interface. In the
       case that the mapping system is just a database (e.g. Redis or
       Casandra) using the common database commands may be sufficient
       without needing additional support in idlocd.

       Identifier-locator mappings are entered into the system through
       the mapping management interfaces. The source of the mapping
       information being entered depends on the application for
       identifier-locator protocols. For instance, in the case that
       identifier-locator protocols are providing mobility in cellular
       networks, the mappings might be set by Mobile Management Entity
       (MME). In a data center where identifier locator split is being
       used to allow task migration, the mappings might be set by a
       distributed job scheduler. Similarly, in network virtualization
       the mappings may be set by a virtualization orchestrator.

3.1.2 Mapping system database

       The mapping system database holds the key/value mappings. A
       mapping system may be implemented in a variety of ways, and it is
       in fact a goal of idlocd to facilitate experimentation and
       development of different alternatives.

       A mapping system is likely to be distributed and would implement
       the necessary mechanisms for synchronization and availability.
       This design allows for a "push", or proactive model, and a "pull"
       or reactive model. Similar to IP routing, the idlocd mapping
       database may be a cache or may contain the full table for the
       site (or at least a particular shard of the full table). Each
       mapping system implements a generic interface that the idlocd
       manager uses.

3.2 ilocd Manager

       The ilocd manager queries or is notified of changes to the
       mapping database via its north interfaces into the mapping
       system. It instantiates these mappings in the dataplane via the



T. Herbert               Expires April 7, 2018                  [Page 7]


INTERNET DRAFT          draft-herbert-idlocd-00


       south interface. The interfaces on both sides are generic such
       that different mapping systems and different dataplanes could be
       supported in arbitrary combinations (again similar in spirit to
       layered interfaces for IP routing).

3.2.1 Interface between idlocd manager and mapping systems

       The interface into the mapping system includes these commands:

     o Get mapping by key

       This is the basic operation to retrieve a mapping. The input key
       is an identifier (likely an IP address), and the output is a
       structure that contains the mapped locator and possibly ancillary
       information of interest to the data plane.

     o Watch key

       The ilocd manager can request notifications in the case that the
       mapping for indicated identifier changes. This would be used to
       implement a pub/sub model.

       The key could be a wildcard meaning that the idlocd manager
       wishes to be notified when any entries in the database changed.
       This might be used in the case of an idlocd router.

     o Notify (callback)

       This is a callback from a mapping systems that a mapping entry
       being watched has changed.

       Additional operations may allow scanning the whole table at
       initialization, providing feedback about the quality if the
       mapping (for instance to invalidate a cache entry that is bad),
       flushing the table, etc.

3.2.2 Interface between ilocd and the dataplane

   This interface provides basic operations

     o Set a mapping in the dataplane

     o Remove a mapping

     o Query mapping

     o Notifications - forced eviction from data plane for instance




T. Herbert               Expires April 7, 2018                  [Page 8]


INTERNET DRAFT          draft-herbert-idlocd-00


3.3 ilocd dataplane

   The dataplane comprises the interface to the idlocd manager, an
   interface into the dataplane mechanism, and the dataplane
   implementation itself. Commands sent by the idlocd manager need to be
   mapped to the interface of the dataplane implementation. Note that
   there are no inherent restrictions on the dataplane implementation,
   this could be a hardware implementation, kernel, userspace, etc.

4  Implementation guidelines

   This section outlines a few design principles for idlocd. As an open
   source project, the hope is to build the generic framework and then
   allow additions (new mapping systems or identifier-locator protocols)
   to be added as modules.

4.1 General requirements

   Some requirements of implementation are:

     o An open source license that allow free use and modification.
       Either GPL or FreeBSD license would be appropriate.

     o Should run on an POSIX compliant OS (Linux, FreeBSD, etc.).

     o Stable version and development branches maintained. Github is a
       candidate mechanism.

     o Unit test framework should be developed. All major code additions
       should include a unit test with stubs as necessary.

4.2 Performance and scalability

   There are expected deployments of identifier-locator protocols where
   performance and scalability are critical. High performance is
   relevant to both the dataplane and control plane. Performance is
   optimized by minimizing the amount of triangular routing and making a
   fast and efficient datapath protocol. For control plane performance,
   convergence time for a mapping change as well as latency to resolve a
   mapping can greatly affect performance.

   Likewise scalability is critical in both datacenter as well as mobile
   device environments. The proliferation of IoT devices potentially
   means that some networks will serve very high numbers of physical
   devices. Virtualization means that the number of addressable nodes in
   a network may exceed the number of physical nodes by several orders
   of magnitudes. The idlocd should be designed to facilitate known
   scalability techniques such as database sharding and minimizing the



T. Herbert               Expires April 7, 2018                  [Page 9]


INTERNET DRAFT          draft-herbert-idlocd-00


   size of in memory data structures.

5  Security Considerations

   Security is very important in identifier-locator mapping protocols.
   Any mapping system must be protected from authorized access that
   could lead to forged mapping entries or leak other data. ilocd should
   therefore run only with admin privileges and software signing should
   be used if idlocd were to allow dynamically loadable modules. Any
   access to a mapping system should have appropriate security. For an
   application to write into a mapping system its credentials must be
   verified and the network communications for this should be encrypted.







































T. Herbert               Expires April 7, 2018                 [Page 10]


INTERNET DRAFT          draft-herbert-idlocd-00


6  IANA Considerations

7  References

7.1  Normative References


7.2  Informative References

8 Acknowledgments

   The author would like to thank Padma Pillay-Esnault, Kalyani
   Bogineni, Niranjan Avula, and Ratul Guha for initial contributions to
   the design in this draft.


Author's Address

   Tom Herbert
   Quantonium
   Santa Clara, CA
   USA


   Email: tom@herbertland.com


























T. Herbert               Expires April 7, 2018                 [Page 11]