idnits 2.17.1 draft-irtf-icnrg-mapme-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date () is 739392 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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, Ed. 4 Intended status: Informational L. Muscariello, Ed. 5 Expires: September 18, 2018 M. Papalini, Ed. 6 Cisco Systems, Inc. 7 mar 17, 2018 9 MAP-Me : Managing Anchorless Mobility in Content Centric Networking 10 draft-irtf-icnrg-mapme-00 12 Abstract 14 Mobility has become a basic premise of network communications, 15 thereby requiring a native integration into 5G networks. Despite 16 numerous efforts to propose and standardize effective mobility- 17 management models for IP, the result is a complex, poorly flexible 18 set of mechanisms. The natural support for mobility offered by ICN 19 (Information Centric Networking) makes it a good candidate to define 20 a radically new solution relieving limitations of the traditional 21 approaches. If consumer mobility is supported in ICN by design, in 22 virtue of its connectionless pull-based communication model, producer 23 mobility is still an open challenge. In this document, we focus on 24 two prominent ICN architectures, CCN (Content Centric Networking) and 25 NDN (Named Data Networking) and describe MAP-Me, an anchor-less 26 solution to manage micro-mobility of content producers via a name- 27 based CCN/NDN data plane, with support for latency-sensitive 28 applications. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 18, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. State-of-the-art and benefits of anchorless mobility 66 solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Design principles . . . . . . . . . . . . . . . . . . . . . . 6 68 4. MAP-Me description . . . . . . . . . . . . . . . . . . . . . 7 69 5. Update protocol . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2. Update propagation . . . . . . . . . . . . . . . . . . . 8 72 5.3. Concurrent updates . . . . . . . . . . . . . . . . . . . 11 73 6. MAP-Me Notification/Discovery protocol . . . . . . . . . . . 12 74 6.1. Interest Notification . . . . . . . . . . . . . . . . . . 13 75 6.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 76 6.3. Full approach . . . . . . . . . . . . . . . . . . . . . . 14 77 7. Implementation . . . . . . . . . . . . . . . . . . . . . . . 14 78 7.1. MAP-Me Messages . . . . . . . . . . . . . . . . . . . . . 14 79 7.2. MAP-Me additional Network Information . . . . . . . . . . 14 80 8. Algorithm description . . . . . . . . . . . . . . . . . . . . 15 81 8.1. IU/IN transmission at producer . . . . . . . . . . . . . 15 82 8.2. IU/IN transmission at network routers . . . . . . . . . . 16 83 8.3. Hop-by-hop IU/IN acknowledgement . . . . . . . . . . . . 16 84 8.4. Face removal at producer/network nodes . . . . . . . . . 17 85 8.5. Consumer request forwarding in case of producer discovery 17 86 9. Security considerations . . . . . . . . . . . . . . . . . . . 19 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 88 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 89 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 92 13.2. Informative References . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 With the phenomenal spread of portable user devices, mobility has 98 become a basic requirement for almost any communication network as 99 well as a compelling feature to integrate in the next generation 100 networks (5G). The need for a mobility-management paradigm to apply 101 within IP networks has striven a lot of efforts in research and 102 standardization bodies (IETF, 3GPP among others), all resulting in a 103 complex access-dependent set of mechanisms implemented via a 104 dedicated control infrastructure. The complexity and lack of 105 flexibility of such approaches (e.g. Mobile IP) calls for a 106 radically new solution dismantling traditional assumptions like 107 tunneling and anchoring of all mobile communications into the network 108 core. \changes{This is particularly important with the increase in 109 rates and mobile nodes (IoT), a vast amount of which never moves.} 111 The Information Centric Network (ICN) paradigm brings native support 112 for mobility, security, and storage within the network architecture, 113 hence emerging as a promising 5G technology candidate. Specifically 114 on mobility management, ICN has the potential to relieve limitations 115 of the existing approaches by leveraging its primary feature, the 116 redefinition of packet forwarding based on _names_ rather than on 117 _network addresses_. We believe that removing the dependence on 118 location identifiers is a first step in the direction of removing the 119 need for any anchoring of communications into fixed network nodes, 120 which may considerably simplify and improve mobility management. 121 Within the ICN paradigm, several architectures have been proposed, as 122 reported in [xylomenos2014survey] and [ahlgren2012survey]. 124 As a direct result of CCN/NDN design principles, consumer mobility is 125 natively supported}: a change in physical location for the consumer 126 does not translate into a change in the data plane like for IP. The 127 retransmission of requests for data not yet received by the consumers 128 takes place without involving any signaling to the network. Producer 129 mobility and realtime group communications present more challenges, 130 depending on the frequency of movements, latency requirements, and 131 content lifetime. The topology does not reflect the naming 132 structure, and we have to preserve key functionalities such as 133 multipath, caching, etc. In all cases, beyond providing connectivity 134 guarantees, additional transport-level mechanisms might be required 135 to protect the flow performance (see [carofiglio2016mwldr] for 136 instance). 138 MAP-Me aims at tackling such problems by exploiting key CCN/NDN 139 characteristics. Previous attempts have been made in CCN/NDN (and 140 ICN in general) literature to go beyond the traditional IP 141 approaches, by using the existing CCN/NDN request/data packet 142 structures to trace producer movements and to dynamically build a 143 reverse-forwarding path (see [NDN-survey] for a survey). They still 144 rely on a stable home address to inform about producer movements or 145 on buffering of incoming requests at the producer's previous point of 146 attachment -- PoA --, which prevents support for latency-sensitive 147 streaming applications. We focus on this class of applications (e.g. 148 live streaming or videoconferencing) as they have the most stringent 149 performance requirements: negligible per-packet loss-rate and delays. 150 In addition, they typically originate from a single producer and 151 don't allow for the use of caching. 153 MAP-Me defines a name-based mechanism operating in the forwarding 154 plane and completely removing any anchoring, while aiming at latency 155 minimization. It has the following characteristics: 157 o MAP-Me addresses micro (e.g. intra Autonomous Systems) producer 158 mobility. Addressing macro-mobility is a non-goal of the 159 proposal. We are focusing here on complementary mechanisms able 160 to provide a fast and lightweight handover, preserving the 161 performance of flows in progress. 163 o MAP-Me does not rely on global routing updates, which would be too 164 slow and too costly, but rather works at a faster timescale 165 propagating forwarding updates and leveraging real-time 166 notifications left as breadcrumbs by the producer to enable live 167 tracking of its position. For simplicity, we use the word 168 'producer' in place of the more correct expression producer name 169 prefixes. The objective being the support of high-speed mobility 170 and real-time group applications 172 o MAP-Me leverages core CCN/NDN features like stateful forwarding, 173 dynamic and distributed Interest load balancing to update the 174 forwarding state at routers, and relaying former and current 175 producer locations. 177 o MAP-Me is designed to be access-agnostic, to cope with highly 178 heterogeneous wireless access and multi-homed/mobile users. 180 o Finally, low overhead in terms of signaling, additional state at 181 routers, and computational complexity are also targeted in the 182 design to provide a solution able to scale to large and dynamic 183 mobile networks. 185 MAP-Me performance has been thoroughly analyzed and provides 186 guarantees of correctness, stability and bounded stretch [MAPME]. 188 2. State-of-the-art and benefits of anchorless mobility solutions 190 Many efforts have been made to define mobility-management models for 191 IP networks in the last two decades, resulting in a variety of 192 complex, often not implemented, proposals. A good survey of these 193 approaches is [RFC6301]. Likewise, within the ICN family, different 194 approaches to mobility management have been presented 195 [tyson2013survey]. 197 When facing high-frequency mobility, those so-called Resolution-Based 198 (RB) approaches present a similar trade-off: for every packet the 199 consumer has to resolve the producer's location or use stale 200 information and run the risk to reach an old position, incurring in 201 timeout, or Nack, etc. 203 Specifically for the CCN/NDN solutions, several surveys of mobility- 204 management approaches can be found [NDN-survey], [feng2016mobility]. 205 In [NDN-survey] for instance, the authors distinguish three 206 categories of solutions -- routing, mapping, and tracing-based -- 207 depending on the type of indirection point (also called Rendez-Vous, 208 RV). We build on such classification and extend it to distinguish a 209 fifth class of approaches not relying upon the existence of any 210 anchor point as the RV (Anchor-less approaches): 212 Routing-based (RT) solutions rely on intra-domain routing, and 213 require updating all routing in the AS after a mobile's 214 movement. Scalability of these solutions is widely recognized 215 as a concern which explains why they are usually ruled out, in 216 particular for CCN/NDN where the name space is even larger than 217 IP. 219 Resolution-based (RB) solutions rely on dedicated RV nodes (similar 220 to DNS) which map content names into routable location 221 identifiers. To maintain this mapping updated, the producer 222 signals every movement to the RV node. Once the resolution is 223 performed, packets can be correctly routed from the consumer 224 along the shortest path, with unitary path stretch (defined as 225 the ratio between the realized path length over the shortest 226 path one). Requiring explicit resolution, together with a 227 strict separation of names and locators, RB solutions involve a 228 scalable CCN/NDN routing infrastructure able to leverage 229 forwarding hints; however, scalability is achieved at the cost 230 of a large hand-off delay as evaluated e.g. in due to RV update 231 and name resolution. To summarize, RB solutions show good 232 scalability properties and low stretch in terms of consumer to 233 producer routing path, but result to be unsuitable for frequent 234 mobility and for reactive rerouting of latency-sensitive 235 traffic, which are key objective of MAP-Me. 237 Anchor-based (AB) proposals are inspired by Mobile IP, and maintain 238 a mapping at network-layer by using a stable home address 239 advertised by a RV node, or anchor. This acts as a relay, 240 forwarding through tunneling both interests to the producer, 241 and data packets coming back. Advantages of this approach are 242 that the consumer does not need to be aware of producer 243 mobility and that it has low signaling overhead because only 244 the anchor has to be updated. It however inherits the 245 drawbacks of Mobile IP -- e.g. triangular routing and single 246 point of failure -- and others more specific to the CCN/NDN 247 context: potential degradation of caching efficiency, bad 248 integrity verification due to the renaming of content during 249 movement. It also hinders multipath capabilities and limits 250 the robustness to failure and congestion initially offered by 251 the architecture. In contrast, MAP-Me maintains names intact 252 and avoid single point-of-passage of the traffic. 254 Tracing-based (TB) solutions allow the mobile node to create a hop- 255 by-hop forwarding reverse path from its RV back to itself by 256 propagating and keeping alive traces stored by all involved 257 routers. Forwarding to the new location is enabled without 258 tunneling. Like AB though, this approach assumes that the data 259 is published under a stable RV prefix. 261 Anchor-less (AL) approaches allow the mobile nodes to advertise 262 their mobility to the network without requiring any specific 263 node to act as a RV. They are less common and introduced in 264 CCN/NDN to enhance the reactivity with respect to AB solutions 265 by leveragingzhang2014kite CCN/NDN name-based routing. The PoA 266 starts buffering incoming Interests for the mobile producer 267 until a forwarding update is completed and a new route is built 268 to reach the current location of the producer. Enhancement of 269 such solutions considers handover prediction. Besides the 270 potentially improved delay performance w.r.t. other categories 271 of approaches, some drawbacks can be recognized: buffering of 272 Interests may lead to timeouts for latency-sensitive 273 applications and handover prediction is hard to perform in many 274 cases. In contrast MAP-Me reacts after the handoff, without 275 requiring handover prediction, and avoids Interests buffering 276 but introduces network notification and discovery mechanism to 277 reduce the handoff latency. 279 3. Design principles 281 MAP-Me is an anchor-less, name-based, layer-2 agnostic approach 282 operating at forwarding plane designed according to the following 283 design principles: 285 o Transparent: MAP-Me does not involve any name nor modifications to 286 basic request/reply operations to be compatible with standard CCN/ 287 NDN design and to avoid issues caused by name modifications like 288 triangular routing, caching degradation, or security 289 vulnerabilities. 291 o Distributed: MAP-Me is designed to be fully distributed, to 292 enhance robustness w.r.t. centralized mobility management 293 proposals subject to single point-of-passage problem. 295 o Localised: MAP-Me updates affect the minimum number of routers at 296 the edge of the network to restore connectivity. The goal is to 297 realize effective traffic off-load close to the end-users. 299 o Lightweight: MAP-Me mobility updates are issued at prefix 300 granularity, rather than content or chunk/packet granularity, to 301 minimize signaling overhead and temporary state kept by in-network 302 nodes; 304 o Reactive: MAP-Me works at forwarding layer to enable updates in 305 FIBs at network latency, i.e. round-trip time scale. Specific 306 mechanisms are defined, referred to as network notifications and 307 discovery, to maximise reactivity in mobility management in case 308 of real-time producer tracking and of latency-sensitive 309 communications; 311 o Robust to network conditions (e.g. routing failure, wireless or 312 congestion losses, and delays), by leveraging hop-by-hop 313 retransmissions of mobility updates. 315 4. MAP-Me description 317 As a data plane protocol, MAP-Me handles producer mobility events by 318 means of dynamic FIB updates with the objective of minimizing 319 unreachability of the producer. It relies on the existence of a 320 routing protocol responsible for creating/updating the FIB of all 321 routers, possibly with multipath routes, and for managing network 322 failures [NLSR]. 324 MAP-Me is composed of: 326 an Update protocol (MAP-ME-IU) (Section Section 5), which is the 327 central component of our proposal; 329 a Notification/Discovery protocol (Section Section 6), to be 330 coupled with the Update protocol (the full approach is referred to 331 as MAP-ME) to enhance reactivity in mobility management for 332 realtime/latency-sensitive application. 334 5. Update protocol 336 5.1. Rationale 338 The rationale behind MAP-Me is that the producer announces its 339 movements to the network by sending a special Interest Packet, named 340 Interest Update (IU) to "itself" after it reattaches to the network. 341 Such a message looks like a regular Interest packet named with the 342 prefix advertised by the producer. As such, it is forwarded 343 according to the information stored in the FIBs of traversed routers 344 towards previous locations of the producer known by router FIBs. A 345 special flag carried in the header of the IU enables all routers on 346 the path to identify the Interest as a mobility update and to process 347 it accordingly to update their FIBs (a detailed description of the IU 348 processing is provided in Sec. Section 8. 350 The key aspect of the proposal is that it removes the need for a 351 stable home address (present in Tracing-Based approaches for 352 instance) by directly leveraging name-based forwarding state created 353 by CCN/NDN routing protocols or left by previous mobility updates. 354 FIB updates are triggered by the reception of mobility updates in a 355 fully distributed way and allow a modification on-the-fly to point to 356 the latest known location of the producer. 358 5.2. Update propagation 360 MAP-ME-IU aims at quickly restoring global reachability of mobile 361 prefixes with low signaling overhead, while introducing a bounded 362 maximum path stretch (i.e. ratio between the selected and the 363 shortest path in terms of hops). 365 Let us illustrate its behavior through the example in 366 Figure Figure 1, where a single producer serving prefix /p moves from 367 position P0 to P1 and so on. Figure Figure 1 (a) shows the tree 368 formed by the forwarding paths to the name prefix /p where IU 369 initiated by the producer propagates. 371 +---+ +---+ 372 | 0 | P0 | 0 | P0 373 +---+ +---+ 374 ^ ^ ^ ^ 375 / \ / \ 376 +---+ +---+ +---+ +---+ 377 | 0 | | 0 | | 0 | | 0 | 378 +---+ +---+ +---+ +---+ 379 ^ ^ ^ ^ 380 / \ / \ 382 +---+ +---+ +---+ +---+ 383 | 0 | | 0 | | 0 | | 0 | 384 +---+ +---+ A +---+ +---+ 385 ^ ^ IU1 / ^ ^ 386 / \ / / \ 387 +---+ +---+ .... .+---+. +---+ 388 | 0 | | 0 | . P1 | 1 | . | 0 | 389 +---+ +---+ . +---+ . +---+ 390 ^ ^ . ^ ^ . 391 / \ . / \ . 392 +---+ +---+ . +---+ +---+ . 393 | 0 | | 0 | . | 0 | | 0 | . 394 +---+ +---+ . +---+ +---+ . 395 .................. 397 (a) (b) 399 ................. 400 +---+ ... +---+ .. 401 | 0 | P0 . | 1 | P0 . 402 +---+ . A +---+ . 403 ^ ^ . IU(1) / / ^ . 404 / \ . / V \ . 405 +---+ +---+ . +---+ +---+ . 406 | 0 | | 0 | . | 1 | | 0 | . 407 +---+ +---+ . A +---+ +---+ . 408 ^ ^ . IU(1) / / ^ . 409 / \ . / V \ . 410 ........+---+. +---+ . +---+ +---+ . 411 . | 1 | . | 0 | . | 1 | | 0 | . 412 . FIB +---+ . +---+ . A +---+ +---+ . 413 . updated / ^ . . IU(1) / / ^ . 414 . V \ .... . / V \ . 415 . +---+ +---+ . . +---+ +---+ . 416 . P1 | 1 | | 0 | . . P1 | 1 | | 0 | . 417 . +---+ +---+ . . +---+ +---+ . 418 . ^ ^ . . ^ ^ . 419 . / \ . . / \ . 420 . +---+ +---+ . . +---+ +---+ . 421 . | 0 | | 0 | . . | 0 | | 0 | . 422 . +---+ +---+ . . +---+ +---+ . 423 .................. .................. 425 (c) (d) 427 +---+ 428 | 1 | P1 429 +---+ 431 ^ A ^ 432 / | \ 433 +---+ +---+ +---+ 434 | 0 | | 0 | | 1 | 435 +---+ +---+ +---+ 436 ^ ^ 437 / \ 438 +---+ +---+ 439 | 0 | | 1 | 440 +---+ +---+ 441 ^ ^ 442 / \ 443 +---+ +---+ 444 P0 | 1 | | 0 | 445 +---+ +---+ 446 ^ 447 / 448 +---+ 449 | 0 | 450 +---+ 452 (e) 454 Figure 1: IU Propagation example 456 Network FIBs are assumed to be populated with routes toward P0 by a 457 name-based routing protocol. After the relocation of the producer 458 from P0 to P1, once the layer-2 attachment is completed, the producer 459 issues an IU carrying the prefix /p and this is forwarded by the 460 network toward P0 (in general, toward one of its previous locations 461 according to the FIB state of the traversed routers). 463 Figure Figure 1 (b) shows the propagation of the IU. As the IU 464 progresses, FIBs at intermediate hops are updated with the ingress 465 face of the IU (Figure Figure 1 (c) and (d)). IU propagation stops 466 when the IU reaches P0 and there is no next hop to forward it. The 467 result is that the original tree rooted in P0 becomes re-rooted in P1 468 (Figure Figure 1 (e)). Looking at the different connected regions 469 (represented with dotted lines), we see that IU propagation and 470 consequent FIB updates have the effect of extending the newly 471 connected subtree (represented as a red cloud): at every step, an 472 additional router and its predecessors are included in the connected 473 subtree. The properties of the update propagation process in terms 474 of bounded length and stretch are studied in [MAPME]. 476 5.3. Concurrent updates 478 Frequent mobility of the producer may lead to the propagation of 479 concurrent updates. To prevent inconsistencies in FIB updates, MAP- 480 Me-IU maintains a sequence number at the producer end that increases 481 at each handover and identifies every IU packet. Network routers 482 also keep track of such sequence number in FIB to verify IU 483 freshness. Without detailing the specific operations in MAP-Me to 484 guarantee update consistency (whose description is provided in 485 Section Section 8, we can say that modification of FIB entries is 486 only triggered when the received IU carries a higher sequence number 487 than the one locally stored, while the reception of a less recent 488 update determines a propagation of a more recent update through the 489 not-yet-updated path. 491 An example of reconciliation of concurrent updates is illustrated in 492 Figure Figure 2 (f), when the producer has moved successively to P1 493 and then to P2 before the first update is completed. 495 +---+ +---+ 496 | 0 | P0 | 2 | P0 497 +---+ A +---+ 498 ^ ^ IU(2) / / ^ 499 / \ / V \ 500 +---+ +---+ +---+ +---+ 501 | 0 | | 0 | | 2 | | 0 | 502 +---+ A +---+ A +---+ A +---+ 503 ^ ^ \ IU(1) / ^ \ \ 504 / \ \ IU(2) / / V \ IU(2) 505 +---+ +---+ +---+ +---+ 506 | 0 | | 2 | P2 | 1 | | 2 | 507 A +---+ +---+ A +---+ +---+ 508 IU(1) / ^ ^ IU1 / / ^ 509 / / \ / V \ 510 +---+ +---+ +---+ +---+ 511 P1 | 1 | | 0 | P1 | 1 | | 0 | 512 +---+ +---+ +---+ +---+ 513 ^ ^ ^ ^ 514 / \ / \ 515 +---+ +---+ +---+ +---+ 516 | 0 | | 0 | | 0 | | 0 | 517 +---+ +---+ +---+ +---+ 519 (f) (g) 521 +---+ +---+ 522 | 2 | P0 | 2 | P2 523 +---+ +---+ 524 / ^ ^ 525 V \ | 526 +---+ +---+ +---+ 527 | 2 | | 2 | | 2 | 528 IU(2) / +---+ +---+ +---+ 529 / ^ \ ^ ^ 530 V / V / \ 531 +---+ +---+ +---+ +---+ 532 | 2 | | 2 | P2 P0 | 2 | | 2 | 533 IU(2) / +---+ +---+ +---+ +---+ 534 / / ^ ^ ^ ^ 535 V V \ / P1 / \ 536 +---+ +---+ +---+ +---+ +---+ 537 P1 | 1 | | 0 | | 0 | | 2 | | 0 | 538 +---+ +---+ +---+ +---+ +---+ 539 ^ ^ ^ ^ 540 / \ / \ 541 +---+ +---+ +---+ +---+ 542 | 0 | | 0 | | 0 | | 0 | 543 +---+ +---+ +---+ +---+ 545 (h) (i) 547 Figure 2 549 Both updates propagate concurrently until the update with sequence 550 number 1 (IU(1)) crosses a router that has been updated with fresher 551 information -- that has received IU with higher sequence number 552 (IU(2)) as in Figure Figure 1 (g). In this case, the router stops 553 the propagation of IU(1) and sends back along its path a new IU with 554 an updated sequence number (Figure 1 (h)). The update proceeds until 555 ultimately the whole network has converged towards P2 (Figure 1 (i)). 557 MAP-Me-IU protocol reacts at a faster timescale than routing -- 558 allowing more frequent and numerous mobility events -- and over a 559 localized portion of the network edge between current and previous 560 producer locations. We thus expect MAP-Me-IU respectively to 561 minimize disconnectivity time and to reduce the link load, which are 562 the main factors affecting user flow performance, as show in [MAPME] 563 evaluations. 565 6. MAP-Me Notification/Discovery protocol 567 IU propagation in the data plane accelerates forwarding state re- 568 convergence w.r.t. global routing (GR) or resolution-based (RB) 569 approaches operating at control plane, and w.r.t. anchor-based (AB) 570 approaches requiring traffic tunneling through the anchor. Still, 571 network latency makes IU completion not instantaneous and before an 572 update completes, it may happen that a portion of the traffic is 573 forwarded to the previous PoA and dropped because of the absence of a 574 valid output face leading to the producer. 576 Previous work in the Anchor-Less category has suggested the buffering 577 of Interests at previous producer location to prevent such losses by 578 increasing network reactivity. However, such a solution is not 579 suitable for applications with stringent latency requirements (e.g. 580 real-time) and may be incompatible with IU completion times. 581 Moreover, the negative effects on latency performance might be 582 further exacerbated by IU losses and consequent retransmissions in 583 case of wireless medium. To alleviate such issues, we introduce two 584 separate enhancements to MAP-Me-IU protocol, namely (i) an _Interest 585 Notification_ mechanism for frequent, yet lightweight, signaling of 586 producer movements to the network and (ii) a scoped _Producer 587 Discovery_ mechanism for consumer requests to proactively search for 588 the producer's recently visited locations. 590 6.1. Interest Notification 592 An Interest Notification (IN) is a breadcrumb left by producers at 593 every encountered PoA. It looks like a normal Interest packet 594 carrying a special identification flag and a sequence number, like 595 IUs. Both IU and IN share the same sequence number (producers 596 indistinctly increase it for every sent message) and follow the same 597 FIB lookup and update processes. However, unlike IU packets, the 598 trace left by INs at the first hop router does not propagate further. 599 It is rather used by the discovery process to route consumer requests 600 to the producer even before an update process is completed. 602 It is worth observing that updates and notifications serve the same 603 purpose of informing the network of a producer movement. \changes{The 604 IU process restores connectivity and as such has higher latency/ 605 signaling cost than the IN process, due to message propagation. The 606 IN process provides information to track producer movements before 607 update completion when coupled with a scoped discovery. The 608 combination of both IU and IN allows to control the trade-off between 609 protocol reactivity and stability of forwarding re-convergence. 611 6.2. Discovery 613 The extension of MAP-Me with notifications relies on a local 614 discovery phase: when a consumer Interest reaches a PoA with no valid 615 output face in the corresponding entry, the Interest is tagged with a 616 _discovery_ flag and labeled with the latest sequence number stored 617 in FIB (to avoid loops). From that point on, it is broadcasted with 618 hop limit equal to one to all neighbors and discarded unless it finds 619 the breadcrumbs left by the producer to track him (notifications). 620 The notifications can either allow to forward consumer Interests 621 directly to the producer or give rise to a repeated broadcast in case 622 of no valid output face. The latter is the case of a breadcrumb left 623 by the producer with no associated forwarding information because the 624 producer has already left that PoA as well. A detailed description 625 of the process is reported in Section 8. 627 The notification/discovery mechanism proves important to preserve the 628 performance of flows in progress, especially when latency-sensitive. 630 6.3. Full approach 632 The full approach is a combined update and notification/discovery 633 approach consisting of sending a IN immediately after an attachment 634 and a IU at most every Tu seconds, referred to as MAP-Me, to reduce 635 signaling overhead especially in case of high mobility. The update- 636 only proposal, denoted as MAP-Me-IU, is equally interesting on its 637 own and might be a fit depending on the use case. 639 7. Implementation 641 In this section we describe the changes to a regular CCN/NDN 642 architecture required to implement MAP-ME and detail the above- 643 described algorithms. This requires to specify a special Interest 644 message, additional temporary information associated to the FIB entry 645 and additional operations to update such entry. 647 7.1. MAP-Me Messages 649 Two new optional fields are introduced in a CCN/NDN Interest header: 651 o a special _Interest Type_ (T) to specify four types of messages: 652 Interest Updates (IU), Interest Notifications (IN), as well as 653 their associated acknowledgment (Ack) messages (IU_Ack and 654 IN_Ack). Those flags are recognized by the forwarding pipeline to 655 trigger special treatment; 657 o a _sequence number_ to handle concurrent updates and prevent 658 forwarding loops during signaling, and to control discovery 659 interests' propagation; 661 7.2. MAP-Me additional Network Information 663 FIB entries are enriched with a sequence number, initialized to 0, 664 say, by routing protocol and updated by MAP-Me upon reception of IU/ 665 IN messages. The Data about not-yet-acknowledged messages are 666 temporarily stored in what we denote as _Temporary FIB buffer, or 667 TFIB_, to ensure reliability of the process, and removed upon 668 reception of the corresponding acknowledgement. 670 As sketched in Figure Figure 3, each TFIB entry is composed of an 671 associative array (F -> T) mapping a face F on which IU has been sent 672 with the associated retransmission timer T (possibly Null). Note 673 that the update mechanism is a constant delay operation at each 674 router and is performed at line rate. 676 IU (IN) input face(s) IU (IN) output face 678 +-----------+-------------------+.......+.......................+ 679 | /prefix | { next hop(s) } | seq | { face : rx_timer } | 680 +-----------+-------------------+.......+.......................+ 681 \_____________ _______________/ \______________ ______________/ 682 V V 683 original FIB TFIB section 685 Figure 3: MAP-ME FIB/TFIB description 687 8. Algorithm description 689 8.1. IU/IN transmission at producer 691 MAP-Me operations are triggered by producer mobility/handover events. 692 At the producer end, a mobility event is followed by a layer-2 693 attachment and, at network layer, a change in the FIB. More 694 precisely, a new face is created and activated upon attachment to a 695 new PoA. This signal triggers the increase of MAP-Me sequence number 696 and the transmission of an IU or IN for every served prefix carrying 697 the updated sequence number. 699 To ensure reliable delivery of IUs, a timer is setup in the temporary 700 section of the FIB entry (TFIB). If an acknowledgement of the IU/IN 701 reception is not received within t seconds since the packet 702 transmission, IU is retransmitted. 704 We define the SendReliably(F, type, E) function fpr sending Special 705 Interests of a given type on faces F based on FIB entry E. It 706 schedules their retransmission through a timer T stored in TFIB: 707 E.TFIB = E.TFIB U (F -> T) and removed on Ack. 709 8.2. IU/IN transmission at network routers 711 At the reception of IU/IN packets, each router performs a name-based 712 Longest Prefix Match lookup in FIB to compare sequence number from 713 IU/IN and from FIB}. According to that comparison: 715 o if the IU/IN packet carries a higher sequence number, the existing 716 next hops associated to the lower sequence number in FIB are used 717 to forward further the IU (INs are not propagated) and temporarily 718 copied into TFIB to avoid loss of such information before 719 completion of the IU/IN acknowledgement process (in case of IN, 720 such entries in TFIB are set with a $\bot$ timer to maintain a 721 trace of the producer recent attachment). Also, the originating 722 face of the IU/IN is added to FIB to route consumer requests to 723 the latest known location of the producer. 725 o If the IU/IN packet carries the same sequence number as in the 726 FIB, the originating face of the IU/IN is added to the existing 727 ones in FIB without additional packet processing or propagation. 728 This may occur in presence of multiple forwarding paths. 730 o If the IU/IN packet carries a lower sequence number than the one 731 in the FIB, FIB entry is not updated as it already stores 'fresher 732 information'. To advertise the latest update through the path 733 followed by the IU/IN packet, this one is re-sent through the 734 originating face after having updated its sequence number with the 735 value stored in FIB. 737 8.3. Hop-by-hop IU/IN acknowledgement 739 The operations in the forwarding pipeline for IU/IN processing are 740 reported in Figure 4. 742 | Algorithm 1 : ForwardSpecialInterest(SpecialInterest SI, Ingress face F) 743 | 744 | CheckValidity() 745 | // Retrieve the FIB entry associated to the prefix 746 | e, T <- FIB.LongestPrefixMatch(SI.name) 747 | if SI.seq >= e.seq then 748 | . // Acknowledge reception 749 | . s <- e.seq 750 | . e.seq <- SI.seq 751 | . SendReliably(F, SI.type + Ack, e) 752 | . //Process special interest 753 | . if F in e.TFIB then 754 | . . // Remove outdated TFIB entry (eventually cancelling timer) 755 | . . e.TFIB = e.TFIB \ F 756 | . if SI.seq > s then 757 | . . if SI.type == IU then 758 | . . . // Forward the IU following the FIB entry 759 | . . . SendReliably(e.NextHops, SI.type, e 760 | . . else 761 | . . . // Create breadcrumb and preserve forwarding structure 762 | . . . e.TFIB = e.TFIB U {( f -> NULL) : for all f in e.NextHops} 763 | . . e.NextHops = {} 764 | . e.NextHops = e.NextHops U { F } 765 | else 766 | . // Send updated IU backwards 767 | . SI.seq = e.seq 768 | . SendReliably(F, SI.type, e) 770 Figure 4 772 8.4. Face removal at producer/network nodes 774 Upon producer departures from a PoA, the corresponding face is 775 destroyed. If this leads to the removal of the last next hop, then 776 faces in TFIB with Null timer (entries generated by notifications) 777 are restored in FIB to preserve the original forwarding tree and thus 778 global connectivity. 780 8.5. Consumer request forwarding in case of producer discovery 782 The forwarding of regular Interests is mostly unaffected in MAP-Me, 783 except in the case of discovery Interests that we detail in Figure 5. 784 The function SendToNeighbors(I) is responsible for broadcasting the 785 Interest I to all neighboring PoAs. 787 | Algorithm 2: InterestForward(Interest I, Origin face F) 788 | 789 | // Regular PIT and CS lookup 790 | e <- FIB.LongestPrefixMatch(I.name) 791 | if e = 0 then 792 | . return 793 | if I.seq = 0 then 794 | . // Regular interest 795 | . if hasValidFace(e.NextHops) or DiscoveryDisabled then 796 | . . ForwardingStrategy.process(I, e) 797 | . else 798 | . . // Enter discovery mode 799 | . . I.seq <- e.seq 800 | . . SendToNeighbors(I) 801 | else 802 | . // Discovery interest: forward if producer is connnected 803 | . if hasProducerFace(e.NextHops) then 804 | . . ForwardingStrategy.process(I, e) 805 | . // Otherwise iterate iif higher seq and breadcrumb 806 | . else if e.seq >= I.seq and EXISTS f | (f -> NULL) in e.TFIB then 807 | . . I.seq <- e.seq 808 | . . SendToNeighbors(I) 810 Figure 5 812 When an Interest arrives to a PoA which has no valid next hop for it 813 (because the producer left and the face got destroyed), it enters a 814 discovery phase where the Interest is flagged as a Discovery Interest 815 and with the local sequence number, then broadcasted to neighboring 816 PoAs. 818 Upon reception of a Discovery Interest, the PoA forwards it direcly 819 to the producer if still attached, otherwise it repeats the one-hop 820 brodcast discovery to neighboring PoAs if it stores a recent 821 notification of the producer presence, i.e. an entry in TFIB having 822 higher sequence number than the one in the Discovery Interest. 823 Otherwise, the Discovery Interest is discarded. 825 It is worth observing that the discovery process is initiated only in 826 the case of no valid next hop, and not every time a notification is 827 found in a router. This is important to guarantee that the 828 notification/discovery process does not affect IU propagation and 829 completion. 831 9. Security considerations 833 All mobility management protocols share the same critical need for 834 securing their control messages which have a direct impact on the 835 forwarding of users' traffic. [compagno2017secure] reviews standard 836 approaches from the literature before developing a fast, lightweight 837 and distributed approach based on hash chaining that can be applied 838 to MAP-Me and fits its design principles. 840 10. Acknowledgements 842 11. Contributors 844 o Giulio Grassi (UPMC/UCLA) 846 o Giovanni Pau (UPMC/UCLA) 848 o Xuan Zeng (UPMC/SystemX) 850 12. IANA Considerations 852 This memo includes no request to IANA. 854 13. References 856 13.1. Normative References 858 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 859 Support in the Internet", RFC 6301, DOI 10.17487/RFC6301, 860 July 2011, . 862 13.2. Informative References 864 [ahlgren2012survey] 865 B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher and B. 866 Ohlman,, "A survey of information-centric networking", 867 IEEE Communications Magazine, vol. 50, no. 7, pp. 26-36, 868 2012. 870 [carofiglio2016mwldr] 871 G. Carofiglio et al., "Leveraging ICN In-network Control 872 for Loss Detection and Recovery in Wireless Mobile 873 Networks", ACM SIGCOMM ICN , 2016. 875 [compagno2017secure] 876 A. Compagno et al., "Secure Producer Mobility in 877 Information-Centric Network", ACM SIGCOMM ICN , 2017. 879 [feng2016mobility] 880 B. Feng et al., "Mobility support in Named Data 881 Networking", EURASIP Journal on Wireless Communications 882 and Networking , 2016. 884 [MAPME] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., 885 Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-less 886 Producer Mobility in Content-Centric Networks", IEEE 887 TNSM, vol. PP, no. 99, pp. 1-1, 2018. 889 [NDN-survey] 890 L. Zhang et al., "Secure Producer Mobility in Information- 891 Centric Network", Workshop on Name-Oriented Mobility: 892 Architecture, Algorithms and Applications , 2016. 894 [NLSR] L. Zhang et al., "Named-data link state routing protocol", 895 ACM SIGCOMM ICN , 2013. 897 [tyson2013survey] 898 G. Tyson et al., "Secure Producer Mobility in Information- 899 Centric Network", Communications of the ACM no. 56, pp. 900 90-98 , 2013. 902 [xylomenos2014survey] 903 G. Xylomenos et al., ""A Survey of Information-Centric 904 Networking Research"", IEEE Communications Surveys & 905 Tutorials vol. 16, no. 2, pp. 1024-1049, 2014. 907 Authors' Addresses 909 Jordan Auge (editor) 910 Cisco Systems, Inc. 912 Email: jordan.auge@cisco.com 914 Giovanna Carofiglio (editor) 915 Cisco Systems, Inc. 917 Email: gcarofig@cisco.com 919 Luca Muscariello (editor) 920 Cisco Systems, Inc. 922 Email: lumuscar@cisco.com 923 Michele Papalini (editor) 924 Cisco Systems, Inc. 926 Email: micpapal@cisco.com