idnits 2.17.1 draft-irtf-icnrg-mapme-01.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 (July 02, 2018) is 2097 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'KITE' is defined on line 784, 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 3 Internet-Draft G. Carofiglio 4 Intended status: Informational L. Muscariello 5 Expires: January 3, 2019 M. Papalini 6 Cisco Systems Inc. 7 July 02, 2018 9 MAP-Me : Managing Anchorless Mobility in Content Centric Networking 10 draft-irtf-icnrg-mapme-01 12 Abstract 14 Consumer mobility is supported in ICN by design, in virtue of its 15 connectionless pull-based communication model; producer mobility 16 through is not natively supported. This document describes MAP-Me, 17 an anchor-less solution to manage micro-mobility of content producers 18 in the CCN (Content Centric Networking) and NDN (Named Data 19 Networking) architectures, with support for latency-sensitive 20 applications. MAP-Me consists in the combination of two data plane 21 protocols, triggered by the producer movements, and leveraging ICN 22 named-based data plane. The main protocol consists in a lightweight 23 FIB update process, complemented by a mechanism of local notification 24 and scoped discovery suitable for low latency applications and fast 25 mobility. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 3, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. MAP-Me overview . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Anchor-less mobility management . . . . . . . . . . . . . 4 64 2.2. Design principles . . . . . . . . . . . . . . . . . . . . 4 65 2.3. MAP-Me protocols . . . . . . . . . . . . . . . . . . . . 5 66 3. Update protocol . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Update propagation . . . . . . . . . . . . . . . . . . . 6 69 3.3. Concurrent updates . . . . . . . . . . . . . . . . . . . 10 70 4. Notification protocol and scoped discovery . . . . . . . . . 11 71 4.1. Interest Notification . . . . . . . . . . . . . . . . . . 12 72 4.2. Scoped discovery . . . . . . . . . . . . . . . . . . . . 12 73 4.3. Full approach . . . . . . . . . . . . . . . . . . . . . . 13 74 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . 13 75 5.1. MAP-Me messages . . . . . . . . . . . . . . . . . . . . . 13 76 5.2. Data structures and temporary state . . . . . . . . . . . 14 77 5.3. Algorithm description . . . . . . . . . . . . . . . . . . 14 78 5.3.1. Producer attachment and face creation . . . . . . . . 14 79 5.3.2. IU/IN transmission at producer . . . . . . . . . . . 14 80 5.3.3. IU/IN transmission at network routers . . . . . . . . 15 81 5.3.4. Consumer request forwarding in case of producer 82 discovery . . . . . . . . . . . . . . . . . . . . . . 16 83 5.3.5. 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 focuses on this class of applications (e.g. live streaming or 146 videoconferencing) as they have the most stringent performance 147 requirements: negligible per-packet loss-rate and delays. In 148 addition, they typically originate from a single producer and don't 149 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 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 and 190 leveraging real-time notifications left as breadcrumbs by the 191 producer, to enable live tracking of its content prefixes and 192 avoid buffering at intermediate nodes. MAP-Me shares the use 193 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 the 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 producer to be 218 aware of the mobility of the remote endpoint, nor producers to 219 perform handover prediction. 221 o *Robust* : to network conditions (e.g. routing failure, wireless 222 or congestion losses, and delays), by leveraging 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 [NLSR]. 234 MAP-Me is composed of: 236 o an Update protocol, detailed in Section 3, which is the central 237 component of our proposal; 239 o a Notification/Discovery protocol, presented in Section 4, to be 240 coupled with the Update protocol to enhance reactivity in mobility 241 management for realtime/latency-sensitive application, and lower 242 overhead during 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 by sending a special Interest Packet, named 250 Interest Update (IU) to "itself" after it reattaches to the network. 251 Such a message looks like a regular Interest packet named with the 252 prefix advertised by the producer. As such, it is forwarded 253 according to the information stored in the FIBs of traversed routers 254 towards previous locations of the producer known by router FIBs. A 255 special flag carried in the header of the IU enables all routers on 256 the path to identify the Interest as a mobility update and to process 257 it 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 state created by CCN/NDN routing protocols or left by previous 263 mobility updates. FIB updates are triggered by the reception of 264 mobility updates in a fully decentralized way and allow a 265 modification on-the-fly to point to the latest known location of the 266 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 (i.e. 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 tree formed by the forwarding paths to the 278 name prefix /p where IU initiated by the producer propagates. 280 +---+ +---+ 281 | 0 | P0 | 0 | P0 282 +---+ +---+ 283 ^ ^ ^ ^ 284 / \ / \ 285 +---+ +---+ +---+ +---+ 286 | 0 | | 0 | | 0 | | 0 | 287 +---+ +---+ +---+ +---+ 288 ^ ^ ^ ^ 289 / \ / \ 290 +---+ +---+ +---+ +---+ 291 | 0 | | 0 | | 0 | | 0 | 292 +---+ +---+ A +---+ +---+ 293 ^ ^ IU1 / ^ ^ 294 / \ / / \ 295 +---+ +---+ .... .+---+. +---+ 296 | 0 | | 0 | . P1 | 1 | . | 0 | 297 +---+ +---+ . +---+ . +---+ 298 ^ ^ . ^ ^ . 299 / \ . / \ . 300 +---+ +---+ . +---+ +---+ . 301 | 0 | | 0 | . | 0 | | 0 | . 302 +---+ +---+ . +---+ +---+ . 303 .................. 305 (a) (b) 307 Figure 1: IU propagation example 308 ................. 309 +---+ ... +---+ .. 310 | 0 | P0 . | 1 | P0 . 311 +---+ . A +---+ . 312 ^ ^ . IU(1) / / ^ . 313 / \ . / V \ . 314 +---+ +---+ . +---+ +---+ . 315 | 0 | | 0 | . | 1 | | 0 | . 316 +---+ +---+ . A +---+ +---+ . 317 ^ ^ . IU(1) / / ^ . 318 / \ . / V \ . 319 ........+---+. +---+ . +---+ +---+ . 320 . | 1 | . | 0 | . | 1 | | 0 | . 321 . FIB +---+ . +---+ . A +---+ +---+ . 322 . updated / ^ . . IU(1) / / ^ . 323 . V \ .... . / V \ . 324 . +---+ +---+ . . +---+ +---+ . 325 . P1 | 1 | | 0 | . . P1 | 1 | | 0 | . 326 . +---+ +---+ . . +---+ +---+ . 327 . ^ ^ . . ^ ^ . 328 . / \ . . / \ . 329 . +---+ +---+ . . +---+ +---+ . 330 . | 0 | | 0 | . . | 0 | | 0 | . 331 . +---+ +---+ . . +---+ +---+ . 332 .................. .................. 334 (a) (b) 336 Figure 2: IU propagation example 337 +---+ 338 | 1 | P1 339 +---+ 340 ^ A ^ 341 / | \ 342 +---+ +---+ +---+ 343 | 0 | | 0 | | 1 | 344 +---+ +---+ +---+ 345 ^ ^ 346 / \ 347 +---+ +---+ 348 | 0 | | 1 | 349 +---+ +---+ 350 ^ ^ 351 / \ 352 +---+ +---+ 353 P0 | 1 | | 0 | 354 +---+ +---+ 355 ^ 356 / 357 +---+ 358 | 0 | 359 +---+ 361 Figure 3: IU propagation example 363 Network FIBs are assumed to be populated with routes toward P0 by a 364 name-based routing protocol. After the relocation of the producer 365 from P0 to P1, once the layer-2 attachment is completed, the producer 366 issues an IU carrying the prefix /p and this is forwarded by the 367 network toward P0 (in general, toward one of its previous locations 368 according to the FIB state of the traversed routers). 370 Figure 1 (b) shows the propagation of the IU. As the IU progresses, 371 FIBs at intermediate hops are updated with the ingress face of the IU 372 (Figure 2 (a) and (b)). IU propagation stops when the IU reaches P0 373 and there is no next hop to forward it. The result is that the 374 original tree rooted in P0 becomes re-rooted in P1 (Figure 3). 375 Looking at the different connected regions (represented with dotted 376 lines), we see that IU propagation and consequent FIB updates have 377 the effect of extending the newly connected subtree : at every step, 378 an additional router and its predecessors are included in the 379 connected subtree. The properties of the update propagation process 380 in terms of bounded length and stretch are studied in [MAPME]. 382 3.3. Concurrent updates 384 Frequent mobility of the producer may lead to the propagation of 385 concurrent updates. To prevent inconsistencies in FIB updates, MAP- 386 Me maintains a sequence number at the producer end that increases at 387 each handover and identifies every IU packet. Network routers also 388 keep track of such sequence number in FIB to verify IU freshness. 389 The modification of FIB entries is only triggered when the received 390 IU carries a higher sequence number than the one locally stored, 391 while the reception of a less recent update determines a propagation 392 of a more recent update through the not-yet-updated path. 394 An example of reconciliation of concurrent updates is illustrated in 395 Figure 4 (a), when the producer has moved successively to P1 and then 396 to P2 before the first update is completed. 398 +---+ +---+ 399 | 0 | P0 | 2 | P0 400 +---+ A +---+ 401 ^ ^ IU(2) / / ^ 402 / \ / V \ 403 +---+ +---+ +---+ +---+ 404 | 0 | | 0 | | 2 | | 0 | 405 +---+ A +---+ A +---+ A +---+ 406 ^ ^ \ IU(1) / ^ \ \ 407 / \ \ IU(2) / / V \ IU(2) 408 +---+ +---+ +---+ +---+ 409 | 0 | | 2 | P2 | 1 | | 2 | 410 A +---+ +---+ A +---+ +---+ 411 IU(1) / ^ ^ IU1 / / ^ 412 / / \ / V \ 413 +---+ +---+ +---+ +---+ 414 P1 | 1 | | 0 | P1 | 1 | | 0 | 415 +---+ +---+ +---+ +---+ 416 ^ ^ ^ ^ 417 / \ / \ 418 +---+ +---+ +---+ +---+ 419 | 0 | | 0 | | 0 | | 0 | 420 +---+ +---+ +---+ +---+ 422 (a) (b) 424 Figure 4 426 +---+ +---+ 427 | 2 | P0 | 2 | P2 428 +---+ +---+ 429 / ^ ^ 430 V \ | 431 +---+ +---+ +---+ 432 | 2 | | 2 | | 2 | 433 IU(2) / +---+ +---+ +---+ 434 / ^ \ ^ ^ 435 V / V / \ 436 +---+ +---+ +---+ +---+ 437 | 2 | | 2 | P2 P0 | 2 | | 2 | 438 IU(2) / +---+ +---+ +---+ +---+ 439 / / ^ ^ ^ ^ 440 V V \ / P1 / \ 441 +---+ +---+ +---+ +---+ +---+ 442 P1 | 1 | | 0 | | 0 | | 2 | | 0 | 443 +---+ +---+ +---+ +---+ +---+ 444 ^ ^ ^ ^ 445 / \ / \ 446 +---+ +---+ +---+ +---+ 447 | 0 | | 0 | | 0 | | 0 | 448 +---+ +---+ +---+ +---+ 450 (a) (b) 452 Figure 5 454 Both updates propagate concurrently until the update with sequence 455 number 1 (IU(1)) crosses a router that has been updated with fresher 456 information - that has received IU with higher sequence number 457 (IU(2)) as in Figure 4 (b). In this case, the router stops the 458 propagation of IU(1) and sends back along its path a new IU with an 459 updated sequence number (Figure 5 (a)). The update proceeds until 460 ultimately the whole network has converged towards P2 (Figure 5 (b)). 462 MAP-Me protocol reacts at a faster timescale than routing - allowing 463 more frequent and numerous mobility events - and over a localized 464 portion of the network edge between current and previous producer 465 locations. This allows to minimize disconnectivity time and reduce 466 link load, which are the main factors affecting user flow 467 performance, as show in [MAPME] evaluations. 469 4. Notification protocol and scoped discovery 471 IU propagation in the data plane accelerates forwarding state re- 472 convergence w.r.t. routing or resolution-based approaches operating 473 at control plane, and w.r.t. anchor-based approaches requiring 474 traffic tunneling through an anchor. Still, network latency makes IU 475 completion not instantaneous and before an update completes, it may 476 happen that a portion of the traffic is forwarded to the previous PoA 477 and dropped because of the absence of a valid output face leading to 478 the producer. 480 Previous work in the Anchor-Less category has suggested the buffering 481 of Interests at previous producer location to prevent such losses by 482 increasing network reactivity. However, such a solution is not 483 suitable for applications with stringent latency requirements (e.g. 484 real-time) and may be incompatible with IU completion times. 485 Moreover, the negative effects on latency performance might be 486 further exacerbated by IU losses and consequent retransmissions in 487 case of wireless medium. To alleviate such issues, we introduce two 488 enhancements to the previously described behavior, namely (i) an 489 "Interest Notification" mechanism for frequent, yet lightweight, 490 signaling of producer movements to the network and (ii) a scoped 491 "Producer Discovery" mechanism for consumer requests to proactively 492 search for the producer's recently visited locations. 494 4.1. Interest Notification 496 An Interest Notification (IN) is a breadcrumb left by producers at 497 every encountered PoA. It looks like a normal Interest packet 498 carrying a special identification flag and a sequence number, like 499 IUs. Both IU and IN share the same sequence number (producers 500 indistinctly increase it for every sent message) and follow the same 501 FIB lookup and update processes. However, unlike IU packets, the 502 trace left by INs at the first hop router does not propagate further. 503 It is rather used by the discovery process to route consumer requests 504 to the producer even before an update process is completed. 506 It is worth observing that updates and notifications serve the same 507 purpose of informing the network of a producer movement. The IU 508 process restores connectivity and as such has higher latency/ 509 signaling cost than the IN process, due to message propagation. The 510 IN process provides information to track producer movements before 511 update completion when coupled with a scoped discovery. The 512 combination of both IU and IN allows to control the trade-off between 513 protocol reactivity and stability of forwarding re-convergence. 515 4.2. Scoped discovery 517 The extension of MAP-Me with notifications relies on a local 518 discovery phase: when a consumer Interest reaches a PoA with no valid 519 output face in the corresponding entry, the Interest is tagged with a 520 "discovery" flag and labeled with the latest sequence number stored 521 in FIB (to avoid loops). From that point on, it is broadcasted with 522 hop limit equal to one to all neighbors and discarded unless it finds 523 the breadcrumbs left by the producer to track him (notifications). 524 The notifications can either allow to forward consumer Interests 525 directly to the producer or give rise to a repeated broadcast in case 526 of no valid output face. The latter is the case of a breadcrumb left 527 by the producer with no associated forwarding information because the 528 producer has already left that PoA as well. A detailed description 529 of the process is reported in Section 5.3. 531 The notification/discovery mechanism proves important to preserve the 532 performance of flows in progress, especially when latency-sensitive. 534 4.3. Full approach 536 The full MAP-Me approach consists in the combination of Updates and 537 Notifications through a heuristic allowing the producer or its PoA to 538 select which type of packet to send. One such heuristic consist in 539 sending a IN immediately after an attachment and a IU at most every 540 Tu seconds, which allows to reduce signaling overhead during periods 541 of high-mobility. The Tu parameter allows to tune the timescale at 542 which Updates occur, and leads to a trade-off between signaling and 543 discovery overhead [MAPME]. The definition of more advanced 544 heuristics is out of scope for the present draft. 546 5. Implementation 548 In this section we describe the changes to a regular CCN/NDN 549 architecture required to implement MAP-ME and detail the above- 550 described algorithms. This requires to specify a special Interest 551 message, additional temporary information associated to the FIB entry 552 and additional operations to update such entry. 554 5.1. MAP-Me messages 556 MAP-Me signaling messages are carried within user plane as special 557 Interest messages corresponding to "update" and "notification", and 558 their corresponding acknowledgements. 560 Two new optional fields are introduced in a CCN/NDN Interest header: 562 o an "Interest Type" (T) used to specify one of the four types of 563 messages: Interest Update (IU), Interest Notification (IN), and as 564 well as their associated acknowledgment (Ack) messages (IU_Ack and 565 IN_Ack). Those flags are recognized by the forwarding pipeline to 566 trigger special treatment; 568 o a "sequence number" to handle concurrent updates and prevent 569 forwarding loops during signaling, and to control discovery 570 Interests' propagation; 572 5.2. Data structures and temporary state 574 FIB entries are augmented with information required for mobility 575 management: 577 o a "sequence number" which is incremented upon reception of IU/IN 578 messages. It can be assumed this counter is set to 0 by the 579 routing protocol. 581 o a buffer storing data about not-yet-acknowledged messages for 582 ensuring reliability of the update process, which we refer to as 583 "Temporary FIB buffer", or "TFIB". As sketched in Figure 6, each 584 TFIB entry is composed of an associative array (F -> T) mapping a 585 face F on which IU has been sent with the associated 586 retransmission timer T (possibly Null). TFIB entries are removed 587 upon reception of the corresponding acknowledgement. 589 IU (IN) input face(s) IU (IN) output face 591 +-----------+-------------------+.......+.......................+ 592 | /prefix | { next hop(s) } | seq | { face : rx_timer } | 593 +-----------+-------------------+.......+.......................+ 594 \_____________ _______________/ \______________ ______________/ 595 V V 596 original FIB TFIB section 598 Figure 6: MAP-Me FIB/TFIB description 600 5.3. Algorithm description 602 5.3.1. Producer attachment and face creation 604 MAP-Me operations are triggered by producer mobility/handover events. 605 At the producer end, a mobility event is followed by a layer-2 606 attachment and, at network layer, a change in the FIB. More 607 precisely, a new face is created and activated upon attachment to a 608 new PoA. 610 5.3.2. IU/IN transmission at producer 612 The creation of a new face on the producer triggers the increase of 613 MAP-Me sequence number and the transmission of an IU or IN for every 614 served prefix carrying the updated sequence number. 616 To ensure reliable delivery of IUs, a timer is setup in the temporary 617 section of the FIB entry (TFIB). If an acknowledgement of the IU/IN 618 reception is not received within t seconds since the packet 619 transmission, IU is retransmitted. 621 We define the following function for sending Special Interests of a 622 given type on faces F based on FIB entry E. 624 SendReliably(F, type, E) 626 It schedules their retransmission through a timer T stored in TFIB, 627 and removed upon reception of the corresponding Ack. 629 E.TFIB = E.TFIB U (F -> T) 631 5.3.3. IU/IN transmission at network routers 633 At the reception of IU/IN packets, each router performs a name-based 634 Longest Prefix Match lookup in FIB to compare sequence number from 635 IU/IN and from FIB. According to that comparison: 637 o if the IU/IN packet carries a higher sequence number, the existing 638 next hops associated to the lower sequence number in FIB are used 639 to forward further the IU (INs are not propagated) and temporarily 640 copied into TFIB to avoid loss of such information before 641 completion of the IU/IN acknowledgement process (in case of IN, 642 such entries in TFIB are set with a Null timer to maintain a trace 643 of the producer recent attachment). Also, the originating face of 644 the IU/IN is added to FIB to route consumer requests to the latest 645 known location of the producer. 647 o If the IU/IN packet carries the same sequence number as in the 648 FIB, the originating face of the IU/IN is added to the existing 649 ones in FIB without additional packet processing or propagation. 650 This may occur in presence of multiple forwarding paths. 652 o If the IU/IN packet carries a lower sequence number than the one 653 in the FIB, FIB entry is not updated as it already stores 'fresher 654 information'. To advertise the latest update through the path 655 followed by the IU/IN packet, this one is re-sent through the 656 originating face after having updated its sequence number with the 657 value stored in FIB. 659 The operations in the forwarding pipeline for IU/IN processing are 660 reported in Figure 7. 662 | Algorithm 1:ForwardSpecialInterest(SpecialInterest SI,IngressFace F) 663 | 664 | CheckValidity() 665 | // Retrieve the FIB entry associated to the prefix 666 | e, T <- FIB.LongestPrefixMatch(SI.name) 667 | if SI.seq >= e.seq then 668 | . // Acknowledge reception 669 | . s <- e.seq 670 | . e.seq <- SI.seq 671 | . SendReliably(F, SI.type + Ack, e) 672 | . //Process special interest 673 | . if F in e.TFIB then 674 | . . // Remove outdated TFIB entry (eventually cancelling timer) 675 | . . e.TFIB = e.TFIB \ F 676 | . if SI.seq > s then 677 | . . if SI.type == IU then 678 | . . . // Forward the IU following the FIB entry 679 | . . . SendReliably(e.NextHops, SI.type, e 680 | . . else 681 | . . . // Create breadcrumb and preserve forwarding structure 682 | . . . e.TFIB = e.TFIB U {(f -> NULL):for all f in e.NextHops} 683 | . . e.NextHops = {} 684 | . e.NextHops = e.NextHops U { F } 685 | else 686 | . // Send updated IU backwards 687 | . SI.seq = e.seq 688 | . SendReliably(F, SI.type, e) 690 Figure 7 692 5.3.4. Consumer request forwarding in case of producer discovery 694 The forwarding of regular Interests is mostly unaffected in MAP-Me, 695 except in the case of discovery Interests that we detail in Figure 8. 696 The function SendToNeighbors(I) is responsible for broadcasting the 697 Interest I to all neighboring PoAs. 699 | Algorithm 2: InterestForward(Interest I, Origin face F) 700 | 701 | // Regular PIT and CS lookup 702 | e <- FIB.LongestPrefixMatch(I.name) 703 | if e = 0 then 704 | . return 705 | if I.seq = 0 then 706 | . // Regular interest 707 | . if hasValidFace(e.NextHops) or DiscoveryDisabled then 708 | . . ForwardingStrategy.process(I, e) 709 | . else 710 | . . // Enter discovery mode 711 | . . I.seq <- e.seq 712 | . . SendToNeighbors(I) 713 | else 714 | . // Discovery interest: forward if producer is connnected 715 | . if hasProducerFace(e.NextHops) then 716 | . . ForwardingStrategy.process(I, e) 717 | . // Otherwise iterate iif higher seq and breadcrumb 718 | . else if e.seq >= I.seq and EXISTS f |(f -> NULL) in e.TFIB then 719 | . . I.seq <- e.seq 720 | . . SendToNeighbors(I) 722 Figure 8 724 When an Interest arrives to a PoA which has no valid next hop for it 725 (because the producer left and the face got destroyed), it enters a 726 discovery phase where the Interest is flagged as a Discovery Interest 727 and with the local sequence number, then broadcasted to neighboring 728 PoAs. 730 Upon reception of a Discovery Interest, the PoA forwards it directly 731 to the producer if still attached, otherwise it repeats the one-hop 732 brodcast discovery to neighboring PoAs if it stores a recent 733 notification of the producer presence, i.e. an entry in TFIB having 734 higher sequence number than the one in the Discovery Interest. 735 Otherwise, the Discovery Interest is discarded. 737 It is worth observing that the discovery process is initiated only in 738 the case of no valid next hop, and not every time a notification is 739 found in a router. This is important to guarantee that the 740 notification/discovery process does not affect IU propagation and 741 completion. 743 5.3.5. Producer departure and face destruction 745 Upon producer departures from a PoA, the corresponding face is 746 destroyed. If this leads to the removal of the last next hop, then 747 faces in TFIB with Null timer (entries generated by notifications) 748 are restored in FIB to preserve the original forwarding tree and thus 749 global connectivity. 751 6. Security considerations 753 All mobility management protocols share the same critical need for 754 securing their control messages which have a direct impact on the 755 forwarding of users' traffic. [SEC] reviews standard approaches from 756 the literature and proposes a fast, lightweight and decentralized 757 approach based on hash chains that can be applied to MAP-Me and fits 758 its design principles. 760 7. Acknowledgements 762 The authors would like to thank Giulio Grassi (UPMC/UCLA), Giovanni 763 Pau (UPMC/UCLA) and Xuan Zeng (Cisco Systems) for their contribution 764 to the work that has led to this document. 766 8. IANA Considerations 768 This memo includes no request to IANA. 770 9. References 772 9.1. Normative References 774 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 775 Support in the Internet", RFC 6301, DOI 10.17487/RFC6301, 776 July 2011, . 778 9.2. Informative References 780 [DATAPLANE] 781 J, ., A, ., A, ., B, ., M, ., and . S, "Ensuring 782 connectivity via data plane mechanisms.", 2013. 784 [KITE] Zhang, Y., Zhang, H., and L. Zhang, "Kite", Proceedings of 785 the 1st international conference on Information-centric 786 networking - INC '14, DOI 10.1145/2660129.2660159, 2014. 788 [MAPME] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., 789 Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less 790 Producer Mobility in Content-Centric Networks", IEEE 791 Transactions on Network and Service Management Vol. 15, 792 pp. 596-610, DOI 10.1109/tnsm.2018.2796720, June 2018. 794 [NLSR] Hoque, A., Amin, S., Alyyan, A., Zhang, B., Zhang, L., and 795 L. Wang, "NISR", Proceedings of the 3rd ACM SIGCOMM 796 workshop on Information-centric networking - ICN '13, 797 DOI 10.1145/2491224.2491231, 2013. 799 [SEC] Compagno, A., Zeng, X., Muscariello, L., Carofiglio, G., 800 and J. Auge, "Secure producer mobility in information- 801 centric network", Proceedings of the 4th ACM Conference on 802 Information-Centric Networking - ICN '17, 803 DOI 10.1145/3125719.3125725, 2017. 805 [SURVEY12] 806 Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., 807 and B. Ohlman, "A survey of information-centric 808 networking", IEEE Communications Magazine Vol. 50, pp. 809 26-36, DOI 10.1109/mcom.2012.6231276, July 2012. 811 [SURVEY13] 812 Tyson, G., Sastry, N., Rimac, I., Cuevas, R., and A. 813 Mauthe, "A survey of mobility in information-centric 814 networks", Proceedings of the 1st ACM workshop on Emerging 815 Name-Oriented Mobile Networking Design - Architecture, 816 Algorithms, and Applications - NoM '12, 817 DOI 10.1145/2248361.2248363, 2012. 819 [SURVEY14] 820 Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., 821 Tsilopoulos, C., Vasilakos, X., Katsaros, K., and G. 822 Polyzos, "A Survey of Information-Centric Networking 823 Research", IEEE Communications Surveys & Tutorials Vol. 824 16, pp. 1024-1049, DOI 10.1109/surv.2013.070813.00063, 825 2014. 827 [SURVEY16a] 828 Feng, B., Zhou, H., and Q. Xu, "Mobility support in Named 829 Data Networking: a survey", EURASIP Journal on Wireless 830 Communications and Networking Vol. 2016, 831 DOI 10.1186/s13638-016-0715-0, September 2016. 833 [SURVEY16b] 834 Zhang, Y., Afanasyev, A., Burke, J., and L. Zhang, "A 835 survey of mobility support in Named Data Networking", 2016 836 IEEE Conference on Computer Communications Workshops 837 (INFOCOM WKSHPS), DOI 10.1109/infcomw.2016.7562050, April 838 2016. 840 [WLDR] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 841 N., and X. Zeng, "Leveraging ICN In-network Control for 842 Loss Detection and Recovery in Wireless Mobile networks", 843 Proceedings of the 2016 conference on 3rd ACM Conference 844 on Information-Centric Networking - ACM-ICN '16, 845 DOI 10.1145/2984356.2984361, 2016. 847 Authors' Addresses 849 Jordan Auge 850 Cisco Systems Inc. 852 Email: augjorda@cisco.com 854 Giovanna Carofiglio 855 Cisco Systems Inc. 857 Email: gcarofig@cisco.com 859 Luca Muscariello 860 Cisco Systems Inc. 862 Email: lumuscar@cisco.com 864 Michele Papalini 865 Cisco Systems Inc. 867 Email: micpapal@cisco.com