Internet DRAFT - draft-herbert-idlocd
draft-herbert-idlocd
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]
