idnits 2.17.1 draft-herbert-idlocd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 4, 2017) is 2389 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Experimental Quantonium 4 Expires: April 2018 6 October 4, 2017 8 Identifier-locator control daemon 9 draft-herbert-idlocd-00 11 Abstract 13 Identifier-locator protocols rely on a mapping system that is able to 14 map identifiers to locators. Such a mapping system is a type of 15 key/value store. This draft proposes a design and implementation for 16 an Identifier-Locator control daemon (idlocd). The intent is to 17 provide an open source implementation that would be a basis for 18 experimentation, development, and eventual deployment of identifier- 19 locator solutions at large scale. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2 Identifier-locator characteristics . . . . . . . . . . . . . . . 3 61 2.1 Encapsulation and non-encapsulation . . . . . . . . . . . . 3 62 2.2 Virtualization and non-virtualization . . . . . . . . . . . 3 63 2.3 Identifier/locator deployment modes . . . . . . . . . . . . 4 64 2.4 Cache management . . . . . . . . . . . . . . . . . . . . . . 5 65 3 General architecture . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1 Mapping system . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1.1 Mapping management . . . . . . . . . . . . . . . . . . . 7 68 3.1.2 Mapping system database . . . . . . . . . . . . . . . . 7 69 3.2 ilocd Manager . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.2.1 Interface between idlocd manager and mapping systems . . 8 71 3.2.2 Interface between ilocd and the dataplane . . . . . . . 8 72 3.3 ilocd dataplane . . . . . . . . . . . . . . . . . . . . . . 9 73 4 Implementation guidelines . . . . . . . . . . . . . . . . . . . 9 74 4.1 General requirements . . . . . . . . . . . . . . . . . . . . 9 75 4.2 Performance and scalability . . . . . . . . . . . . . . . . 9 76 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 77 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 78 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 80 7.2 Informative References . . . . . . . . . . . . . . . . . . 11 81 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 1 Introduction 86 This document proposes creation of an open source project to define 87 and implement a control daemon for identifier-locator protocols. A 88 goal of this is to provide a platform to facilitate development of a 89 mapping system and protocols for the IDEAS effort in IETF. 91 The identifier-locator daemon, or "idlocd", will be designed and 92 implemented in the same spirit as open source routing daemons like 93 gated, BIRD, or Quagga. It should be able to support different 94 mapping systems and different identifier-locator protocols. 96 2 Identifier-locator characteristics 98 This section provides some background on different characteristics of 99 identifier-locator protocols that are relevant to a control plane 100 implementation. 102 2.1 Encapsulation and non-encapsulation 104 Identifier-locator protocols can be divided into two classes: those 105 based on encapsulation and those that are not. 107 Encapsulation based protocols include VXLAN and LISP. In this model, 108 the identifiers and locators are IP addresses (IPv4 or IPv6). In the 109 dataplane, a packet considered to be addressed by an identifier is 110 encapsulated with another IP header whose destination address is a 111 locator. 113 Identifier-locator protocols that do not use encapsulation include 114 ILA and ILNP. In this case, an IP address is split into a locator and 115 identifier component. In the dataplane, the locator portion of the 116 address (which is routable) is set to the appropriate locator. 118 idloc should be able to gracefully serve both types assuming the 119 details of the particular protocol are properly abstracted. The 120 mapping system will need to contain the correctly sized identifier 121 and locators for the protocol in use, and it may also provide 122 additional information for the dataplane (e.g. protocol specific 123 options for encapsulation). 125 2.2 Virtualization and non-virtualization 127 Network virtualization is typically implemented using overlay 128 networks. In network virtualization, virtual addresses are mapped to 129 physical addresses for delivery. This is isomorphic to the mapping of 130 identifiers to locators, and hence a common mechanism can be used in 131 idlocd. Network virtualization includes the concept of different 132 virtual networks that are represented by a Virtual Network Identifier 133 (VNI). To accommodate that in idlocd, the identifier key used to look 134 up a mapping in an idlocd database could be a concatenation of a VNI 135 and a virtual address. 137 2.3 Identifier/locator deployment modes 139 Identifier-locator mapping can be performed at different parts of the 140 network. 142 The figure below illustrates three possible network deployments: 144 +------+ +------+ 145 | Host +--+ +----| Host | 146 | | | (') | | 147 +------+ | ............ ( ) +------+ 148 | +--------+ . . +--------+ (_) 149 | | idloc |--. .--| idloc | | 150 +--|fwcache | . L3 . | router |--+ 151 +--------+ . network . +--------| 152 / . . 153 / . . +-------++-------+ 154 +------+ / . . | idloc || Host | 155 | Host +--+ . .--| host || | 156 | | ........... +-------++-------+ 157 +------+ 159 Note that "hosts" in this diagram could be a virtual or physical 160 endpoints. This includes servers, UEs, tasks, VMs, or anything else 161 that can be addressed. 163 The idloc deployment variants are: 165 o Router 167 This is a node that performs identifier-locator mapping within 168 the network. These are nodes that forward packets based on a 169 mapping and perform encapsulation or address translation for the 170 associated identifier-locator protocol. A group of idloc routers 171 synchronize a shared database so that each router has the set of 172 mappings for the domain they serve. The mapping database could be 173 sharded across a set of routers so that each router maintains 174 only the mappings for the shard it serves. 176 o Fwcache (forwarding cache) 178 This is similar to an idloc router in that it performs forwarding 179 and encapsulation of an identifier-locator protocol, however the 180 mapping table it maintains is a cache. A protocol is used to 181 query an idloc router to resolve mappings and populate the cache. 182 The specifics of cache management are dependent of the mapping 183 system, and similar to other types of cache resolution scenarios 184 (neighbor discovery, ARP, DNS) there are a number of possible 185 approaches. 187 o Host 189 This is an instance of identifier-locator mapping that runs 190 directly on the host. The mapping system for this is most likely 191 a cache (like in fwcache), but it's also possible to implement a 192 router and participate in the idloc router protocols. Since an 193 idloc host is integrated into the host stack, the implementation 194 may include optimizations to leverage that. For instance, the 195 result of a mapping look up for a connection might be done only 196 once if the mapping information is cached in the connection 197 context (the ILA implementation currently does this). 199 2.4 Cache management 201 In identifier-locator protocols, a mapping cache may be populated 202 by a "push" or a "pull" model. In the push model, changes to the 203 mapping database are proactively pushed to nodes. A pub/sub model 204 may be implemented to limit the announcement of changes only to 205 those nodes that are interested. The pub/sub model is very good 206 for communicating changes with low latency and limiting messages 207 to interested parties, however it is stateful and could be 208 difficult to scale. 210 In the "pull" model, a node initiates a request for mapping data 211 when it needs to send. The request can be explicit or implicit. 213 In the explicit case, a node uses a request/response resolution 214 protocol (similar to ARP). The target is an identifier that needs 215 to be resolved to a locator, and the request is sent to a router 216 that has access to the mapping table which contains the 217 identifier. 219 For the implicit case, a node sends a packet using a default 220 locator that routes a packet to an idloc router. In addition to 221 performing encapsulation or translation to forward the packet, 222 the router may also send back a redirect message that contains 223 the locator for the identifier that was used. Upon receiving the 224 redirect message, a node may subsequently use the indicated 225 locator to send to the associated identifier. 227 The pull model is stateless and possibly more scalable than push 228 model, however latency of propagating changes may be greater. An 229 implicit pull model requires fewer packets to be sent than an 230 explicit one, however an implicit resolution protocol is harder 231 to secure against message spoofing. 233 Additional cache management may include expiration timeouts, 234 eviction due to memory constraints, and LRU management of 235 evictions. 237 idlocd should be able to support the various caching models 238 described above. A instance of a mapping system might be tightly 239 coupled with the dataplane implementation of a protocol. For 240 instance, to perform an explicit resolution, the mapping system 241 may need a callback in the datapath for when a packet is sent to 242 an unresolved identifier. 244 3 General architecture 246 The stack of idlocd is: 248 +---------------------------+ \ 249 | Mapping management | | 250 +---------------------------+ | Mapping system 251 | Mapping system DB | | 252 +---------------------------+ / 253 | 254 +---------------------------+ 255 | ilocd manager | 256 +---------------------------+ 257 | 258 +---------------------------+ \ 259 | Dataplane interface | | 260 +---------------------------+ | Dataplane 261 | Dataplane implementation | | 262 +---------------------------+ / 264 There are three major layers in this design: the mapping system 265 and the dataplane contain specific implementations of mapping 266 systems and identifier-locator dataplanes. The ilocd manager is 267 generalized to be the interface between the mapping system and 268 dataplane. 270 3.1 Mapping system 272 The mapping systems layer consists of different implementations 273 or protocols. This design allows for experimentation and 274 development for different mapping systems with different 275 characteristics. This includes potential use of databases and 276 NoSQL databases (such as Redis and Casandra), routing protocols 277 (BGP for instance), simple map files, or other variants. The 278 specifics of each mapping system are contained in a software 279 module, and an interface abstraction is use to provide mappings 280 to the ilocd manager. 282 3.1.1 Mapping management 284 This is the external interface into a mapping system. It is used 285 to set identifier to locator mappings, remove them, and to query 286 the database. The interfaces may be specific to the mapping 287 system or ilocd may provide them an generic interface. In the 288 case that the mapping system is just a database (e.g. Redis or 289 Casandra) using the common database commands may be sufficient 290 without needing additional support in idlocd. 292 Identifier-locator mappings are entered into the system through 293 the mapping management interfaces. The source of the mapping 294 information being entered depends on the application for 295 identifier-locator protocols. For instance, in the case that 296 identifier-locator protocols are providing mobility in cellular 297 networks, the mappings might be set by Mobile Management Entity 298 (MME). In a data center where identifier locator split is being 299 used to allow task migration, the mappings might be set by a 300 distributed job scheduler. Similarly, in network virtualization 301 the mappings may be set by a virtualization orchestrator. 303 3.1.2 Mapping system database 305 The mapping system database holds the key/value mappings. A 306 mapping system may be implemented in a variety of ways, and it is 307 in fact a goal of idlocd to facilitate experimentation and 308 development of different alternatives. 310 A mapping system is likely to be distributed and would implement 311 the necessary mechanisms for synchronization and availability. 312 This design allows for a "push", or proactive model, and a "pull" 313 or reactive model. Similar to IP routing, the idlocd mapping 314 database may be a cache or may contain the full table for the 315 site (or at least a particular shard of the full table). Each 316 mapping system implements a generic interface that the idlocd 317 manager uses. 319 3.2 ilocd Manager 321 The ilocd manager queries or is notified of changes to the 322 mapping database via its north interfaces into the mapping 323 system. It instantiates these mappings in the dataplane via the 324 south interface. The interfaces on both sides are generic such 325 that different mapping systems and different dataplanes could be 326 supported in arbitrary combinations (again similar in spirit to 327 layered interfaces for IP routing). 329 3.2.1 Interface between idlocd manager and mapping systems 331 The interface into the mapping system includes these commands: 333 o Get mapping by key 335 This is the basic operation to retrieve a mapping. The input key 336 is an identifier (likely an IP address), and the output is a 337 structure that contains the mapped locator and possibly ancillary 338 information of interest to the data plane. 340 o Watch key 342 The ilocd manager can request notifications in the case that the 343 mapping for indicated identifier changes. This would be used to 344 implement a pub/sub model. 346 The key could be a wildcard meaning that the idlocd manager 347 wishes to be notified when any entries in the database changed. 348 This might be used in the case of an idlocd router. 350 o Notify (callback) 352 This is a callback from a mapping systems that a mapping entry 353 being watched has changed. 355 Additional operations may allow scanning the whole table at 356 initialization, providing feedback about the quality if the 357 mapping (for instance to invalidate a cache entry that is bad), 358 flushing the table, etc. 360 3.2.2 Interface between ilocd and the dataplane 362 This interface provides basic operations 364 o Set a mapping in the dataplane 366 o Remove a mapping 368 o Query mapping 370 o Notifications - forced eviction from data plane for instance 372 3.3 ilocd dataplane 374 The dataplane comprises the interface to the idlocd manager, an 375 interface into the dataplane mechanism, and the dataplane 376 implementation itself. Commands sent by the idlocd manager need to be 377 mapped to the interface of the dataplane implementation. Note that 378 there are no inherent restrictions on the dataplane implementation, 379 this could be a hardware implementation, kernel, userspace, etc. 381 4 Implementation guidelines 383 This section outlines a few design principles for idlocd. As an open 384 source project, the hope is to build the generic framework and then 385 allow additions (new mapping systems or identifier-locator protocols) 386 to be added as modules. 388 4.1 General requirements 390 Some requirements of implementation are: 392 o An open source license that allow free use and modification. 393 Either GPL or FreeBSD license would be appropriate. 395 o Should run on an POSIX compliant OS (Linux, FreeBSD, etc.). 397 o Stable version and development branches maintained. Github is a 398 candidate mechanism. 400 o Unit test framework should be developed. All major code additions 401 should include a unit test with stubs as necessary. 403 4.2 Performance and scalability 405 There are expected deployments of identifier-locator protocols where 406 performance and scalability are critical. High performance is 407 relevant to both the dataplane and control plane. Performance is 408 optimized by minimizing the amount of triangular routing and making a 409 fast and efficient datapath protocol. For control plane performance, 410 convergence time for a mapping change as well as latency to resolve a 411 mapping can greatly affect performance. 413 Likewise scalability is critical in both datacenter as well as mobile 414 device environments. The proliferation of IoT devices potentially 415 means that some networks will serve very high numbers of physical 416 devices. Virtualization means that the number of addressable nodes in 417 a network may exceed the number of physical nodes by several orders 418 of magnitudes. The idlocd should be designed to facilitate known 419 scalability techniques such as database sharding and minimizing the 420 size of in memory data structures. 422 5 Security Considerations 424 Security is very important in identifier-locator mapping protocols. 425 Any mapping system must be protected from authorized access that 426 could lead to forged mapping entries or leak other data. ilocd should 427 therefore run only with admin privileges and software signing should 428 be used if idlocd were to allow dynamically loadable modules. Any 429 access to a mapping system should have appropriate security. For an 430 application to write into a mapping system its credentials must be 431 verified and the network communications for this should be encrypted. 433 6 IANA Considerations 435 7 References 437 7.1 Normative References 439 7.2 Informative References 441 8 Acknowledgments 443 The author would like to thank Padma Pillay-Esnault, Kalyani 444 Bogineni, Niranjan Avula, and Ratul Guha for initial contributions to 445 the design in this draft. 447 Author's Address 449 Tom Herbert 450 Quantonium 451 Santa Clara, CA 452 USA 454 Email: tom@herbertland.com