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