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]