idnits 2.17.1 draft-irtf-icnrg-mapme-05.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 (June 2020) is 1410 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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 icnrg J. Auge, Ed. 3 Internet-Draft G. Carofiglio 4 Intended status: Informational L. Muscariello 5 Expires: 11 December 2020 M. Papalini 6 Cisco Systems Inc. 7 June 2020 9 MAP-Me : Managing Anchorless Mobility in Content Centric Networking 10 draft-irtf-icnrg-mapme-05 12 Abstract 14 Consumer mobility is supported in ICN by design, in virtue of its 15 connectionless pull-based communication model; producer mobility 16 though is not natively supported. This document describes MAP-Me, an 17 anchor-less solution to manage micro-mobility of content producers in 18 the CCN (Content Centric Networking) and NDN (Named Data Networking) 19 architectures, with support for latency-sensitive applications. MAP- 20 Me consists in the combination of two data plane protocols, triggered 21 by producer movements, and leveraging ICN named-based data plane. 22 The main protocol consists in a lightweight FIB update process, 23 complemented by a mechanism of local notification and scoped 24 discovery suitable for low latency applications and fast mobility. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 3 December 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. MAP-Me overview . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Anchor-less mobility management . . . . . . . . . . . . . 4 62 2.2. Design principles . . . . . . . . . . . . . . . . . . . . 4 63 2.3. MAP-Me protocols . . . . . . . . . . . . . . . . . . . . 5 64 3. Update protocol . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Update propagation . . . . . . . . . . . . . . . . . . . 6 67 3.3. Concurrent updates . . . . . . . . . . . . . . . . . . . 10 68 4. Notification protocol and scoped discovery . . . . . . . . . 12 69 4.1. Interest Notification . . . . . . . . . . . . . . . . . . 12 70 4.2. Scoped discovery . . . . . . . . . . . . . . . . . . . . 13 71 4.3. Full approach . . . . . . . . . . . . . . . . . . . . . . 13 72 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . 13 73 5.1. MAP-Me messages . . . . . . . . . . . . . . . . . . . . . 13 74 5.2. Data structures and temporary state . . . . . . . . . . . 14 75 5.3. Algorithm description . . . . . . . . . . . . . . . . . . 14 76 5.3.1. Producer attachment and face creation . . . . . . . . 15 77 5.3.2. IU/IN transmission at producer . . . . . . . . . . . 15 78 5.3.3. IU/IN transmission at network routers . . . . . . . . 15 79 5.3.4. Reliable transmission . . . . . . . . . . . . . . . . 16 80 5.3.5. Consumer request forwarding in case of producer 81 discovery . . . . . . . . . . . . . . . . . . . . . . 17 82 5.3.6. Producer departure and face destruction . . . . . . . 18 83 6. Security considerations . . . . . . . . . . . . . . . . . . . 18 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 88 9.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Introduction 93 With the phenomenal spread of portable user devices, mobility has 94 become a basic requirement for almost any communication network as 95 well as a compelling feature to integrate in the next generation 96 networks (5G). The need for a mobility-management paradigm to apply 97 within IP networks has striven a lot of efforts in research and 98 standardization bodies (IETF, 3GPP among others), all resulting in a 99 complex access-dependent set of mechanisms implemented via a 100 dedicated control infrastructure. The complexity and lack of 101 flexibility of such approaches (e.g. Mobile IP) calls for a 102 radically new solution dismantling traditional assumptions like 103 tunneling and anchoring of all mobile communications into the network 104 core. This is particularly important with the increase in rates and 105 mobile nodes (IoT), a vast amount of which never moves. 107 The Information Centric Network (ICN) paradigm brings native support 108 for mobility, security, and storage within the network architecture, 109 hence emerging as a promising 5G technology candidate. Specifically 110 on mobility management, ICN has the potential to relieve limitations 111 of the existing approaches by leveraging its primary feature, the 112 redefinition of packet forwarding based on "names" rather than 113 "network addresses". Removing the dependence on location identifiers 114 is a first step in the direction of removing the need for any 115 anchoring of communications into fixed network nodes, which may 116 considerably simplify and improve mobility management. Within the 117 ICN paradigm, several architectures have been proposed, as reported 118 in [SURVEY12] and [SURVEY14]. 120 As a direct result of CCN/NDN design principles, consumer mobility is 121 natively supported: a change in physical location for the consumer 122 does not translate into a change in the data plane like for IP. The 123 retransmission of requests for data not yet received by the consumer 124 takes place without involving any signaling to the network. Producer 125 mobility and realtime group communications present more challenges, 126 depending on the frequency of movements, latency requirements, and 127 content lifetime. The topology does not reflect the naming 128 structure, and the mobility management process has to preserve key 129 functionalities such as multipath, caching, etc. In all cases, 130 beyond providing connectivity guarantees, additional transport-level 131 mechanisms might be required to protect the flow performance (see 132 [WLDR] for instance). 134 MAP-Me aims at tackling such problems by exploiting key CCN/NDN 135 characteristics. Previous attempts have been made in CCN/NDN (and 136 ICN in general) literature to go beyond the traditional IP 137 approaches, by using the existing CCN/NDN request/data packet 138 structures to trace producer movements and to dynamically build a 139 reverse-forwarding path (see [SURVEY16b] for a survey). They still 140 rely on a stable home address to inform about producer movements or 141 on buffering of incoming requests at the producer's previous point of 142 attachment (PoA), which prevents support for latency-sensitive 143 streaming applications. The approach presented in this document 144 makes a particular focus on this class of applications (e.g. live 145 streaming or videoconferencing) as they have the most stringent 146 performance requirements: negligible per-packet loss-rate and delays. 147 In addition, they typically originate from a single producer and 148 don't allow for the use of caching. 150 MAP-Me defines a name-based mechanism operating in the forwarding 151 plane and completely removing any anchoring, while aiming at latency 152 minimization. Its performance and guarantees of correctness, 153 stability and bounded stretch are analyzed in [MAPME]. 155 2. MAP-Me overview 157 2.1. Anchor-less mobility management 159 Many efforts have been made to define mobility-management models for 160 IP networks in the last two decades, resulting in a variety of 161 complex, often not implemented, proposals. A survey of these 162 approaches is proposed in [RFC6301]. Likewise, within ICN, different 163 approaches to mobility management have been presented [SURVEY13]. 164 Specifically for the CCN/NDN solutions, several surveys of mobility- 165 management approaches can be found [SURVEY16a] [SURVEY16b]. 167 We follow here the classification presented in [MAPME] which 168 highlights their reliance on indirection/rendez-vous points. In 169 particular, a new class of anchor-less approaches is introduced, in 170 which the present proposal fits. Such solutions are less common and 171 have been introduced in ICN to remove the need for anchor points in 172 the data plane, but also in the control plane in the form of 173 resolution or mapping services. These solutions completely remove 174 the use of locators and extend the ICN forwarding mechanisms with 175 mobility support. 177 2.2. Design principles 179 * *Micro-Mobility* : MAP-Me addresses micro (e.g. intra Autonomous 180 Systems) producer mobility. Addressing macro-mobility is a non- 181 goal of the proposal. We are focusing here on complementary 182 mechanisms able to provide a fast and lightweight handover, 183 preserving the performance of flows in progress. 185 - *Control Plane Agnostic* : MAP-Me _is control-plane agnostic as 186 it does not rely on routing updates or path computation_, which 187 would be too slow and too costly, but rather works at a faster 188 timescale propagating forwarding updates on a single path. It 189 also leverages real-time notifications left as breadcrumbs by 190 the producer to enable live tracking of its content prefixes 191 and avoid buffering at intermediate nodes. MAP-Me shares the 192 use of data plane mechanisms for ensuring connectivity with 193 [DATAPLANE] which was originally proposed for link failures. 194 This enables the support of high-speed mobility and real-time 195 group applications. In addition, MAP-Me mobility updates are 196 issued at prefix granularity, rather than content or chunk/ 197 packet granularity, to minimize signaling overhead and 198 temporary state kept by in-network nodes, and scale to large 199 and dynamic mobile networks. 201 * *Access-agnostic* : MAP-Me handles mobility at Layer 3 and is 202 designed to be access-agnostic, to cope with highly heterogeneous 203 wireless access and multi-homed/mobile users. 205 * *Decentralized and localized* : MAP-Me is designed to be fully 206 _decentralized_, to enhance robustness w.r.t. centralized mobility 207 management proposals subject to single point-of-passage problem. 208 MAP-Me updates are _localized_ and affect a minimum number of 209 routers at the edge of the network to restore connectivity. This 210 effectively realizes traffic off-load close to the end-users. 212 * *Transparent* : MAP-Me does not involve any name nor modifications 213 to basic request/reply operations to be compatible with standard 214 CCN/NDN design and to avoid issues caused by name modifications 215 like triangular routing, caching degradation, or security 216 vulnerabilities. It does not require consumers or producers to be 217 aware of the mobility of the remote endpoint, nor to perform any 218 handover prediction. 220 * *Robust* : to network conditions (e.g. routing failure, wireless 221 or congestion losses, and delays), by implementing hop-by-hop 222 retransmissions of mobility updates. 224 2.3. MAP-Me protocols 226 As a data plane protocol, MAP-Me handles producer mobility events by 227 means of dynamic FIB updates with the objective of minimizing 228 unreachability of the producer. It relies on the existence of a 229 routing protocol responsible for creating/updating the FIB of all 230 routers, possibly with multipath routes, and for managing network 231 failures (eg. [NLSR]). 233 MAP-Me is composed of: 235 * an Update protocol, detailed in Section 3, which is the central 236 component of the proposal; 238 * a Notification/Discovery protocol, presented in Section 4, which 239 is coupled with the Update protocol to enhance reactivity for 240 realtime/latency-sensitive application, and reduce overhead during 241 fast mobility events. 243 3. Update protocol 245 3.1. Rationale 247 The rationale behind MAP-Me is that the producer announces its 248 movements to the network for all served prefixes, by sending a 249 special Interest packet - named Interest Update (IU) - to "itself" 250 after it reattaches to the network. Such a message looks like a 251 regular Interest packet named with the prefix advertised by the 252 producer. As such, it is forwarded according to the information 253 stored in the FIBs of traversed routers towards all previous 254 locations of the producer known by router FIBs. A special flag 255 carried in the header of the IU enables all routers on the path to 256 identify the Interest as a mobility update and to process it 257 accordingly to update their FIBs (a detailed description of the IU 258 processing is provided in Section 5.3). 260 The key aspect of the proposal is that it removes the need for a 261 stable home address by directly leveraging name-based forwarding 262 information created by CCN/NDN routing protocols, and eventually 263 further updated due to mobility. FIB updates are triggered by the 264 reception of mobility updates in a fully decentralized way and allow 265 an on-the-fly modification to point to the latest known location of 266 the producer. 268 3.2. Update propagation 270 The role of the update process is to quickly restore global 271 reachability of mobile prefixes with low signaling overhead, while 272 introducing a bounded maximum path stretch (the ratio between the 273 selected and the shortest path in terms of hops). 275 Let us illustrate its behavior through an example where a single 276 producer serving prefix /p moves from position P0 to P1 and so on. 277 Figure 1 (a) shows the initial tree formed by the forwarding paths to 278 the name prefix /p, and on which any IU initiated by the producer 279 will propagate. 281 +---+ +---+ 282 | 0 | P0 | 0 | P0 283 +---+ +---+ 284 ^ ^ ^ ^ 285 / \ / \ 286 +---+ +---+ +---+ +---+ 287 | 0 | | 0 | | 0 | | 0 | 288 +---+ +---+ +---+ +---+ 289 ^ ^ ^ ^ 290 / \ / \ 291 +---+ +---+ +---+ +---+ 292 | 0 | | 0 | | 0 | | 0 | 293 +---+ +---+ A +---+ +---+ 294 ^ ^ IU1 / ^ ^ 295 / \ / / \ 296 +---+ +---+ .... .+---+. +---+ 297 | 0 | | 0 | . P1 | 1 | . | 0 | 298 +---+ +---+ . +---+ . +---+ 299 ^ ^ . ^ ^ . 300 / \ . / \ . 301 +---+ +---+ . +---+ +---+ . 302 | 0 | | 0 | . | 0 | | 0 | . 303 +---+ +---+ . +---+ +---+ . 304 .................. 306 (a) (b) 308 Figure 1: IU propagation example 309 ................. 310 +---+ ... +---+ .. 311 | 0 | P0 . | 1 | P0 . 312 +---+ . A +---+ . 313 ^ ^ . IU(1) / / ^ . 314 / \ . / V \ . 315 +---+ +---+ . +---+ +---+ . 316 | 0 | | 0 | . | 1 | | 0 | . 317 +---+ +---+ . A +---+ +---+ . 318 ^ ^ . IU(1) / / ^ . 319 / \ . / V \ . 320 ........+---+. +---+ . +---+ +---+ . 321 . | 1 | . | 0 | . | 1 | | 0 | . 322 . FIB +---+ . +---+ . A +---+ +---+ . 323 . updated / ^ . . IU(1) / / ^ . 324 . V \ .... . / V \ . 325 . +---+ +---+ . . +---+ +---+ . 326 . P1 | 1 | | 0 | . . P1 | 1 | | 0 | . 327 . +---+ +---+ . . +---+ +---+ . 328 . ^ ^ . . ^ ^ . 329 . / \ . . / \ . 330 . +---+ +---+ . . +---+ +---+ . 331 . | 0 | | 0 | . . | 0 | | 0 | . 332 . +---+ +---+ . . +---+ +---+ . 333 .................. .................. 335 (a) (b) 337 Figure 2: IU propagation example 338 +---+ 339 | 1 | P1 340 +---+ 341 ^ A ^ 342 / | \ 343 +---+ +---+ +---+ 344 | 0 | | 0 | | 1 | 345 +---+ +---+ +---+ 346 ^ ^ 347 / \ 348 +---+ +---+ 349 | 0 | | 1 | 350 +---+ +---+ 351 ^ ^ 352 / \ 353 +---+ +---+ 354 P0 | 1 | | 0 | 355 +---+ +---+ 356 ^ 357 / 358 +---+ 359 | 0 | 360 +---+ 362 Figure 3: IU propagation example 364 Network FIBs are assumed to be populated with routes towards P0 by a 365 name-based routing protocol. After the relocation of the producer 366 from P0 to P1, once the layer-2 attachment is completed, the producer 367 issues an IU carrying the prefix /p and this is forwarded by the 368 network toward P0 (in general, toward one of its previous locations 369 according to the FIB state of traversed routers). 371 Figure 1 (b) illustrates the propagation of the IU. As the IU 372 progresses, FIBs at intermediate hops are updated with the ingress 373 face of the IU (Figure 2 (a) and (b)). IU propagation stops when the 374 IU reaches P0 and there is no next hop to forward it to. The result 375 is that the original tree rooted in P0 becomes re-rooted in P1 376 (Figure 3). Looking at the different connected regions (represented 377 with dotted lines), we see that IU propagation and consequent FIB 378 updates have the effect of extending the newly connected subtree : at 379 every step, an additional router and its predecessors are included in 380 the connected subtree. 382 3.3. Concurrent updates 384 Frequent mobility of the producer may lead to the propagation of 385 concurrent updates. To prevent inconsistencies in FIBs, MAP-Me 386 maintains a sequence number at the producer end that is incremented 387 at each handover and associated to all sent IU packets. Network 388 routers also keep track of such sequence number in their FIBs to 389 validate the relative freshness of received updates. The 390 modification of FIB entries is only triggered when the received IU 391 carries a higher sequence number than the locally stored one, while 392 the reception of a less recent update triggers the transmission of a 393 more up-to-date IU backwards in order to fix the not-yet-updated 394 path. 396 An example reconciliation of concurrent updates is illustrated in 397 Figure 4 (a), when the producer has moved successively to P1 and then 398 to P2 before the first update could complete. 400 +---+ +---+ 401 | 0 | P0 | 2 | P0 402 +---+ A +---+ 403 ^ ^ IU(2) / / ^ 404 / \ / V \ 405 +---+ +---+ +---+ +---+ 406 | 0 | | 0 | | 2 | | 0 | 407 +---+ A +---+ A +---+ A +---+ 408 ^ ^ \ IU(1) / ^ \ \ 409 / \ \ IU(2) / / V \ IU(2) 410 +---+ +---+ +---+ +---+ 411 | 0 | | 2 | P2 | 1 | | 2 | 412 A +---+ +---+ A +---+ +---+ 413 IU(1) / ^ ^ IU1 / / ^ 414 / / \ / V \ 415 +---+ +---+ +---+ +---+ 416 P1 | 1 | | 0 | P1 | 1 | | 0 | 417 +---+ +---+ +---+ +---+ 418 ^ ^ ^ ^ 419 / \ / \ 420 +---+ +---+ +---+ +---+ 421 | 0 | | 0 | | 0 | | 0 | 422 +---+ +---+ +---+ +---+ 424 (a) (b) 426 Figure 4 428 +---+ +---+ 429 | 2 | P0 | 2 | P2 430 +---+ +---+ 431 / ^ ^ 432 V \ | 433 +---+ +---+ +---+ 434 | 2 | | 2 | | 2 | 435 IU(2) / +---+ +---+ +---+ 436 / ^ \ ^ ^ 437 V / V / \ 438 +---+ +---+ +---+ +---+ 439 | 2 | | 2 | P2 P0 | 2 | | 2 | 440 IU(2) / +---+ +---+ +---+ +---+ 441 / / ^ ^ ^ ^ 442 V V \ / P1 / \ 443 +---+ +---+ +---+ +---+ +---+ 444 P1 | 1 | | 0 | | 0 | | 2 | | 0 | 445 +---+ +---+ +---+ +---+ +---+ 446 ^ ^ ^ ^ 447 / \ / \ 448 +---+ +---+ +---+ +---+ 449 | 0 | | 0 | | 0 | | 0 | 450 +---+ +---+ +---+ +---+ 452 (a) (b) 454 Figure 5 456 Both updates propagate concurrently until the one with sequence 457 number 1 (IU(1)) crosses a router that has been updated with fresher 458 information. In the example shown in Figure 4 (b), the junction 459 router has already received an IU with higher sequence number 460 (IU(2)). In this case, the router stops the propagation of IU(1) and 461 sends back along its path a new IU with an updated sequence number 462 (Figure 5 (a)). The update proceeds until the whole network has 463 ultimately converged towards P2 (Figure 5 (b)). 465 MAP-Me protocol reacts at a faster timescale than routing - allowing 466 more frequent and numerous mobility events - and over a localized 467 portion of the network edge between current and previous producer 468 locations. This allows to minimize disconnectivity time and reduce 469 link load, which are the main factors affecting user flow 470 performance, as shown in [MAPME] evaluations. 472 4. Notification protocol and scoped discovery 474 IU propagation in the data plane is designed to accelerate forwarding 475 state re-convergence w.r.t. routing or resolution-based approaches 476 operating at control plane, and w.r.t. anchor-based approaches 477 requiring traffic tunneling through an anchor node. Still, network 478 latency makes IU completion not instantaneous and before an update 479 completes, it may happen that a portion of the traffic is forwarded 480 to the previous PoA and dropped because of the absence of a valid 481 output face leading to the producer. 483 Previous work in the Anchor-Less category has suggested the buffering 484 of Interests at previous producer location to prevent those losses. 485 However, such a solution is not suitable for applications with 486 stringent latency requirements (e.g. real-time) and may be 487 incompatible with IU completion times. Moreover, the negative 488 effects on latency performance might be further exacerbated by IU 489 losses and consequent retransmissions in case of wireless medium. To 490 alleviate such issues, we introduce two enhancements to the 491 previously described behavior, namely (i) an "Interest Notification" 492 mechanism for frequent, yet lightweight, signaling of producer 493 movements to the network and (ii) a scoped "Producer Discovery" 494 mechanism for consumer requests to proactively search for the 495 producer's recently visited locations. 497 4.1. Interest Notification 499 An Interest Notification (IN) is a breadcrumb left by producers at 500 every encountered PoA. It looks like a normal Interest packet 501 carrying a special identification flag and a sequence number, like 502 IUs. Both IU and IN share the same sequence number (producers 503 indistinctly increase it for every sent message) and follow the same 504 FIB lookup and update processes. However, unlike IU packets, the 505 trace left by INs at the first hop router does not propagate further. 506 It is rather used by the discovery process to route consumer requests 507 to the producer even before an update process is completed. 509 It is worth observing that updates and notifications serve the same 510 purpose of informing the network of a producer movement. The IU 511 process restores connectivity and as such has higher latency/ 512 signaling cost than the IN process, due to message propagation. The 513 IN process provides information to track producer movements before 514 update completion when coupled with a scoped discovery. The 515 combination of both IU and IN allows to control the trade-off between 516 protocol reactivity and stability of forwarding re-convergence. 518 4.2. Scoped discovery 520 The extension of MAP-Me with notifications relies on a local 521 discovery phase: when a consumer Interest reaches a PoA with no valid 522 output face in the corresponding entry, the Interest is tagged with a 523 "discovery" flag and labeled with the latest sequence number stored 524 in FIB (to avoid loops). From that point on, it is broadcasted with 525 hop limit equal to one to all neighbors and discarded unless it finds 526 a breadcrumb left by the producer with a higher sequence number. The 527 notifications can either allow to forward consumer Interests directly 528 to the producer or give rise to a repeated broadcast in case of no 529 valid output face. The latter is the case of a breadcrumb left by 530 the producer with no associated forwarding information because the 531 producer has already left that PoA as well. A detailed description 532 of the process is reported in Section 5.3. 534 The notification/discovery mechanism proves important to preserve the 535 performance of flows in progress, especially when latency-sensitive. 537 4.3. Full approach 539 The full MAP-Me approach consists in the combination of Updates and 540 Notifications through a heuristic allowing the producer or its PoA to 541 select which type of packet to send. One such heuristic consist in 542 sending a IN immediately after an attachment and a IU at most every 543 Tu seconds, which allows to reduce signaling overhead during periods 544 of high-mobility. The Tu parameter allows to tune the timescale at 545 which Updates occur, and leads to a trade-off between signaling and 546 discovery overhead [MAPME]. The definition of more advanced 547 heuristics is out of scope for the present draft. 549 5. Implementation 551 In this section we describe the changes to a regular CCN/NDN 552 architecture required to implement MAP-ME and detail the above- 553 described algorithms. This requires to specify a special Interest 554 message, additional temporary information associated to the FIB entry 555 and additional operations to update such entry. 557 5.1. MAP-Me messages 559 MAP-Me signaling messages are carried within user plane as special 560 Interest messages corresponding to "update" and "notification", and 561 their corresponding acknowledgements. 563 Two new optional fields are introduced in a CCN/NDN Interest header: 565 * an "Interest Type" (T) used to specify one of the four types of 566 messages: Interest Update (IU), Interest Notification (IN), and as 567 well as their associated acknowledgment (Ack) messages (IU_Ack and 568 IN_Ack). Those flags are recognized by the forwarding pipeline to 569 trigger special treatment; 571 * a "sequence number" to handle concurrent updates and prevent 572 forwarding loops during signaling, and to control discovery 573 Interests' propagation; 575 5.2. Data structures and temporary state 577 FIB entries are augmented with information required for mobility 578 management, that we denote as Transient FIB buffer, or simply TFIB, 579 and sketch in Figure 6: 581 * a "sequence number" which is incremented upon reception of IU/IN 582 messages. It can be assumed this counter is set to 0 by the 583 routing protocol. 585 * a list of so-called "previous next hop(s)" (further denoted as 586 PrevHops), similar to the list of NextHops in the original FIB, 587 which temporarily stores information about faces that were 588 previously next hops, and should still be memorized to allow for 589 retransmissions and thus ensure the consistency of MAP-Me 590 operations. They typically correspond to nodes for which an IU 591 has been sent, but no acknowledgement (ACK) has yet been received 592 (upon which they are cleared). In case of notifications, no ACK 593 is expected, and those entries serve as a memory of the former 594 tree structure that will be restored upon producer departure. We 595 flag those entries with a boolean marker indicating if they 596 correspond to an IU (and thus should be monitored for 597 retransmissions) or an IN (in which case they just serve as memory 598 for further use). 600 IU (IN) input face(s) IU (IN) output face 602 +-----------+-------------------+.......+..........................+ 603 | /prefix | { next hop(s) } | seq | { previous next hop(s) } | 604 +-----------+-------------------+.......+..........................+ 605 \_____________ _______________/ \_______________ _______________/ 606 V V 607 original FIB TFIB section 609 Figure 6: MAP-Me FIB/TFIB description 611 5.3. Algorithm description 612 5.3.1. Producer attachment and face creation 614 MAP-Me operations are triggered by a change of adjacencies in the 615 network, reflected in the forwarder by the creation or removal of a 616 face. This can be for instance the layer 2 detachment and attachment 617 following a mobility/handover event, but also any other mechanism 618 such as point-to-point IP link or UDP tunnel for instance, as allowed 619 by the forwarder implementation. 621 One realization of this architecture is to delegate face management 622 to a third party agent, keeping the ICN forwarder state synchronized 623 with the underlying topology, and having MAP-Me only react to changes 624 in the face table. 626 5.3.2. IU/IN transmission at producer 628 The creation of a new face on the producer triggers the increase of 629 MAP-Me sequence number and the transmission for every locally served 630 prefix, of an IU or IN carrying the updated sequence number. 632 5.3.3. IU/IN transmission at network routers 634 At the reception of IU/IN packets, each router performs a name-based 635 Longest Prefix Match lookup in FIB to compare sequence number from 636 IU/IN and from FIB. According to that comparison: 638 * if the IU/IN packet carries a higher sequence number, the existing 639 next hops associated to the lower sequence number in FIB are used 640 to forward further the IU (INs are not propagated) and temporarily 641 copied into TFIB to avoid loss of such information before 642 completion of the IU/IN acknowledgement process. The ingress face 643 of the IU/IN is then added to FIB to route consumer requests to 644 the latest known location of the producer. 646 * If the IU/IN packet carries the same sequence number as in the 647 FIB, the originating face of the IU/IN is added to the existing 648 ones in FIB without additional packet processing or propagation. 649 This may occur in presence of multiple forwarding paths. 651 * If the IU/IN packet carries a lower sequence number than the one 652 in the FIB, FIB entry is not updated as it already stores 'fresher 653 information'. To advertise the latest update through the path 654 followed by the IU/IN packet, this one is re-sent through the 655 originating face after having updated its sequence number with the 656 value stored in FIB. 658 The operations in the forwarding pipeline for IU/IN processing are 659 reported in Figure 7, where we make use of the following primitives: 660 - Send(Interest, Face) is used to send the specified Interest on the 661 specified Face. - ProcessTFIB() sends an IU for all flagged entries 662 in the TFIB, using the latest sequence number stored in the FIB 663 entry, and schedule the entry to be checked for retransmissions. 665 | Alg. 1:ForwardSpecialInterest(SpecialInterest SI,IngressFace F) 666 | 667 | CheckValidity() 668 | // Acknowledge reception 669 | s <- e.seq 670 | e.seq <- SI.seq 671 | Send(IU_Ack(e.seq), F) 672 flag <- (SI.type == IU) 673 | // Retrieve the FIB entry associated to the prefix 674 | e <- FIB.LongestPrefixMatch(SI.name) 675 | if SI.seq >= e.seq then 676 | . //Process special interest 677 | . e.TFIB = e.TFIB \ { F } 678 | . if SI.seq > s then 679 | . . e.TFIB = e.TFIB U { (f, flag) | f in (e.NextHops \ F) } 680 . . ProcessTFIB() 681 | . . e.NextHops = {} 682 | . e.NextHops = e.NextHops U { F } 683 | else 684 | . // Send updated IU backwards 685 | . SI.seq = e.seq 686 | . e.TFIB = e.TFIB U { (F, flag) } 687 | . ProcessTFIB() 689 Figure 7 691 5.3.4. Reliable transmission 693 MAP-Me ensure the reliable delivery of signaling messages thanks to a 694 retransmission timer which reissue Interest Updates (eventually 695 carrying updated sequence number as found in the FIB), if no 696 corresponding ACK has been received in a predefined interval, and 697 whose sequence number has to match the one stored in the FIB. 699 A slotted implementation of such scheme is possible by using a single 700 timer, and keeping a list of FIB entries that require to be checked 701 for pending retransmissions in the next slot. Upon timer expiration, 702 if all required ACKs have been received, the TFIB will be empty and 703 the entry does not have to be tracked anymore. Otherwise, necessary 704 retransmissions are performed and the entry will be checked again in 705 the next slot. When no entry has to be monitored, the process can 706 sleep until the next mobility event. 708 5.3.5. Consumer request forwarding in case of producer discovery 710 The forwarding of regular Interests is mostly unaffected in MAP-Me, 711 except in the case of discovery Interests that we detail in Figure 8. 712 The function SendToNeighbors(I) is responsible for broadcasting the 713 Interest I to all neighboring PoAs. 715 | Alg. 2: InterestForward(Interest I, Origin face F) 716 | 717 | // Regular PIT and CS lookup 718 | e <- FIB.LongestPrefixMatch(I.name) 719 | if e = 0 then 720 | . return 721 | if I.seq = 0 then 722 | . // Regular interest 723 | . if hasValidFace(e.NextHops) or DiscoveryDisabled then 724 | . . ForwardingStrategy.process(I, e) 725 | . else 726 | . . // Enter discovery mode 727 | . . I.seq <- e.seq 728 | . . SendToNeighbors(I) 729 | else 730 | . // Discovery interest: forward if producer is connnected 731 | . if hasProducerFace(e.NextHops) then 732 | . . ForwardingStrategy.process(I, e) 733 | . // Otherwise iterate iif higher seq and breadcrumb 734 | . else if e.seq >= I.seq and \ 735 | EXISTS f | (f -> NULL) in e.TFIB then 736 | . . I.seq <- e.seq 737 | . . SendToNeighbors(I) 739 Figure 8 741 When an Interest arrives to a PoA which has no valid next hop for it 742 (because the producer left and the face got destroyed), it enters a 743 discovery phase where the Interest is flagged as a Discovery Interest 744 and with the local sequence number, then broadcasted to neighboring 745 PoAs. 747 Upon reception of a Discovery Interest, the PoA forwards it directly 748 to the producer if still attached, otherwise it repeats the one-hop 749 brodcast discovery to neighboring PoAs if it stores a recent 750 notification of the producer presence, i.e. an entry in TFIB having 751 higher sequence number than the one in the Discovery Interest. 752 Otherwise, the Discovery Interest is discarded. 754 It is worth observing that the discovery process is initiated only in 755 the case of no valid next hop, and not every time a notification is 756 found in a router. This is important to guarantee that the 757 notification/discovery process does not affect IU propagation and 758 completion. 760 5.3.6. Producer departure and face destruction 762 Upon producer departures from a PoA, the corresponding face is 763 destroyed. If this leads to the removal of the last next hop, then 764 faces in TFIB corresponding to IN are restored as next hops in the 765 FIB so as to preserve the original forwarding tree and thus global 766 connectivity. 768 6. Security considerations 770 All mobility management protocols share the same critical need for 771 securing their control messages which have a direct impact on the 772 forwarding of users' traffic. [SEC] reviews standard approaches from 773 the literature and proposes a fast, lightweight and decentralized 774 approach based on hash chains that can be applied to MAP-Me and fits 775 its design principles. 777 7. Acknowledgements 779 The authors would like to thank Giulio Grassi (UPMC/UCLA), Giovanni 780 Pau (UPMC/UCLA) and Xuan Zeng (UPMC/SystemX) for their contribution 781 to the work that has led to this document. 783 8. IANA Considerations 785 This memo includes no request to IANA. 787 9. References 789 9.1. Normative References 791 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 792 Support in the Internet", RFC 6301, DOI 10.17487/RFC6301, 793 July 2011, . 795 9.2. Informative References 797 [DATAPLANE] 798 J, ., A, ., A, ., B, ., M, ., and . S, "Ensuring 799 connectivity via data plane mechanisms.", 2013. 801 [MAPME] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., 802 Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less 803 Producer Mobility in Content-Centric Networks", 804 DOI 10.1109/tnsm.2018.2796720, IEEE Transactions on 805 Network and Service Management Vol. 15, pp. 596-610, June 806 2018, . 808 [NLSR] Hoque, A., Amin, S., Alyyan, A., Zhang, B., Zhang, L., and 809 L. Wang, "NISR", DOI 10.1145/2491224.2491231, Proceedings 810 of the 3rd ACM SIGCOMM workshop on Information-centric 811 networking - ICN '13, 2013, 812 . 814 [SEC] Compagno, A., Zeng, X., Muscariello, L., Carofiglio, G., 815 and J. Auge, "Secure producer mobility in information- 816 centric network", DOI 10.1145/3125719.3125725, Proceedings 817 of the 4th ACM Conference on Information- 818 Centric Networking, September 2017, 819 . 821 [SURVEY12] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., 822 and B. Ohlman, "A survey of information-centric 823 networking", DOI 10.1109/mcom.2012.6231276, IEEE 824 Communications Magazine Vol. 50, pp. 26-36, July 2012, 825 . 827 [SURVEY13] Tyson, G., Sastry, N., Rimac, I., Cuevas, R., and A. 828 Mauthe, "A survey of mobility in information-centric 829 networks", DOI 10.1145/2248361.2248363, Proceedings of the 830 1st ACM workshop on Emerging Name-Oriented Mobile 831 Networking Design - Architecture, Algorithms, and 832 Applications - NoM '12, 2012, 833 . 835 [SURVEY14] Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., 836 Tsilopoulos, C., Vasilakos, X., Katsaros, K., and G. 837 Polyzos, "A Survey of Information-Centric Networking 838 Research", DOI 10.1109/surv.2013.070813.00063, IEEE 839 Communications Surveys & Tutorials Vol. 16, pp. 1024-1049, 840 2014, . 842 [SURVEY16a] 843 Feng, B., Zhou, H., and Q. Xu, "Mobility support in Named 844 Data Networking: a survey", DOI 10.1186/s13638-016-0715-0, 845 EURASIP Journal on Wireless Communications and 846 Networking Vol. 2016, September 2016, 847 . 849 [SURVEY16b] 850 Zhang, Y., Afanasyev, A., Burke, J., and L. Zhang, "A 851 survey of mobility support in Named Data Networking", 852 DOI 10.1109/infcomw.2016.7562050, 2016 IEEE Conference on 853 Computer Communications Workshops (INFOCOM WKSHPS), April 854 2016, . 856 [WLDR] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 857 N., and X. Zeng, "Leveraging ICN In-network Control for 858 Loss Detection and Recovery in Wireless Mobile networks", 859 DOI 10.1145/2984356.2984361, Proceedings of the 2016 860 conference on 3rd ACM Conference on Information-Centric 861 Networking - ACM-ICN '16, 2016, 862 . 864 Authors' Addresses 866 Jordan Auge (editor) 867 Cisco Systems Inc. 868 11, rue Camille Desmoulins 869 92130 Issy-les-Moulineaux 870 France 872 Email: augjorda@cisco.com 874 Giovanna Carofiglio 875 Cisco Systems Inc. 876 11, rue Camille Desmoulins 877 92130 Issy-les-Moulineaux 878 France 880 Email: gcarofig@cisco.com 882 Luca Muscariello 883 Cisco Systems Inc. 884 11, rue Camille Desmoulins 885 92130 Issy-les-Moulineaux 886 France 887 Email: lumuscar@cisco.com 889 Michele Papalini 890 Cisco Systems Inc. 891 11, rue Camille Desmoulins 892 92130 Issy-les-Moulineaux 893 France 895 Email: micpapal@cisco.com