idnits 2.17.1 draft-auge-dmm-hicn-mobility-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 == Line 705 has weird spacing: '...failure o e...' -- The document date (8 July 2020) is 1388 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2275 (Obsoleted by RFC 2575) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-04) exists of draft-auge-dmm-hicn-mobility-deployment-options-03 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group J. Auge 3 Internet-Draft G. Carofiglio 4 Intended status: Informational L. Muscariello 5 Expires: 9 January 2021 M. Papalini 6 Cisco 7 8 July 2020 9 Anchorless mobility through hICN 10 draft-auge-dmm-hicn-mobility-04 12 Abstract 14 This document first discusses the use of locators and identifiers in 15 mobility management architectures, and their implication on various 16 anchorless properties. A new architecture is then proposed that is 17 purely based on identifiers, and more specifically names as defined 18 in Hybrid-ICN (hICN). The document then focuses on two main cases: 19 the end-point sends data (data producer) or the end-point receives 20 data (data consumer). These two cases are taken into account 21 entirely to provide anchorless mobility management in hICN. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 9 January 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Locators, identifiers and anchorless mobility management . . 3 58 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Towards locator-independent network architectures . . . . 4 60 2.3. Information-Centric Networking (ICN) . . . . . . . . . . 6 61 2.4. Hybrid-ICN overview . . . . . . . . . . . . . . . . . . . 6 62 3. Hybrid-ICN Anchorless Mobility Management (hICN-AMM) . . . . 6 63 3.1. Consumer mobility in hICN . . . . . . . . . . . . . . . . 7 64 4. Producer mobility architectures . . . . . . . . . . . . . . . 7 65 4.1. Producer mobility in hICN . . . . . . . . . . . . . . . . 8 66 5. Protocol description . . . . . . . . . . . . . . . . . . . . 8 67 5.1. Signalization messages; acknowledgements and 68 retransmission . . . . . . . . . . . . . . . . . . . . . 9 69 5.2. Dynamic face creation and producer-triggered 70 advertisements . . . . . . . . . . . . . . . . . . . . . 9 71 5.3. Update protocol . . . . . . . . . . . . . . . . . . . . . 10 72 5.3.1. Illustration . . . . . . . . . . . . . . . . . . . . 10 73 5.3.2. Message content . . . . . . . . . . . . . . . . . . . 11 74 5.3.3. Processing at network routers . . . . . . . . . . . . 12 75 5.4. Notifications and scoped discovery . . . . . . . . . . . 12 76 5.4.1. Notification processing . . . . . . . . . . . . . . . 12 77 5.4.2. Illustration . . . . . . . . . . . . . . . . . . . . 13 78 6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.2. Simplicity, scalability, efficiency . . . . . . . . . . . 15 81 6.3. Reduced latency through caching . . . . . . . . . . . . . 15 82 6.4. Improved reliability through caching . . . . . . . . . . 17 83 6.5. Local mobility and recovery from common cache . . . . . . 17 84 6.6. Additional reliability through consumer multihoming . . . 18 85 6.7. Bandwidth aggregation with consumer multihoming . . . . . 20 86 6.8. Traffic and signalization offload . . . . . . . . . . . . 21 87 7. Implementation considerations . . . . . . . . . . . . . . . . 22 88 7.1. Interaction with non-hICN enabled routers . . . . . . . . 23 89 7.2. Security considerations . . . . . . . . . . . . . . . . . 23 90 7.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 23 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 94 9.2. Informative References . . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 97 1. Introduction 99 New usages of the network and the rapid growth of the Mobile Internet 100 calls to reconsider the way we deploy and operate IP networks, where 101 mobility is not built into the design, but rather added as an 102 afterthought. Notable examples are IETF Mobile IP and its variants 103 [RFC5944] and [RFC2275] 3GPP GTP-based architecture [TS29.274], both 104 based on tunnelling and encapsulation. 106 One identified difficulty in proposing mobility models for IP lies in 107 the semantic overloading of IP addresses which are both host 108 identifiers, and locators used for routing. Starting with LISP, the 109 identifier/locator split paradigm has shown promising results in 110 virtue of its scalability properties with respect to routing tables 111 entries, and the possibilities it offers in terms of mobility. 112 Several solutions have been proposed around this concept, namely 113 ILNP, ILSR, and ILA. One common facet of these proposals is to 114 embrace the current trend of a clear separation between the control 115 and data planes, which both allows for distribution of the control 116 infrastructure, as well as anchorless operations in the data plane, 117 including facilitated local breakout. 119 The counterpart of these architectures is an increased dependency on 120 the control plane which is responsible for binding the identifiers 121 used by the application at the edge to the locators used to forward 122 the traffic in the network. Device mobility will typically induce a 123 change of IP address, which makes performance of flows in progress 124 dependent on interactions with those control elements which have to 125 remain globally consistent. 127 In this document, we first propose to clarify protocol descriptions 128 by adopting a new terminology of control-plane and data-plane anchors 129 to characterize anchorless operations, and show their tight coupling 130 with the use of locators and identifiers. This definition serves to 131 position Loc/ID-split architectures with respect to the traditional 132 use of tunnels, before advocating to push this step further and 133 perform mobility management purely based on identifiers. We 134 introduce a mobility approach based on Hybrid ICN (hICN) as described 135 in [I-D.muscariello-intarea-hicn], for which we perform an in-depth 136 analysis of mobility considerations. We show how this proposal can 137 help addressing further challenges faced by networks today, such as 138 multihoming and multipath, while preserving the simplicity and end- 139 to-end design of the current Internet. 141 2. Locators, identifiers and anchorless mobility management 142 2.1. Terminology 144 The consideration of mobility in network design shares the challenges 145 raised for routing for instance in [RFC6115], where the terminology 146 for locators and identifiers is presented. 148 Because they are intrinsically bound to the topological location of a 149 node, session established through locators require additional 150 mechanisms to support mobility, including the presence of anchor 151 points in the network. The notion of _anchor_ and the resulting 152 _anchorless_ properties of mobility schemes are prone to different 153 interpretation depending on the context. The following definitions 154 attempt to reconcile those interpretations and propose a unifying 155 terminology used throughout this document. 157 Anchor An anchor refers to a specialized node or service, possibly 158 distributed, functionally required by a network architecture for 159 forwarding or mobility. This is in contrast to decentralized 160 architectures. Configuration of these anchors, including their 161 location, will directly affect the overall scheme performance. We 162 follow the classic distinction between control plane and user (or 163 data, or forwarding) plane to distinguish control-plane anchors 164 and user-plane anchors. 166 User-plane anchor A user-plane anchor is a node through which 167 traffic is forced to pass. An example of such anchor is the 168 indirection point in Mobile IP. 170 Control-plane anchor A control-plane anchor refers to a node that is 171 not responsible for carrying traffic, but is needed for the 172 operation of the forwarding and/or the mobility architecture. An 173 example of such anchor is the resolution or mapping service of 174 LISP. We remark that while not being on path, such anchors might 175 affect the performance of the user-plane due to resolution delays 176 or indirection (following a mapping cache miss for instance). 178 Anchorless This term qualifies approaches that do not involve any 179 user-plane not control-plane anchor. The challenge for such full 180 anchorless approaches are exacerbated during mobilty of both end 181 points at the same time, as they cannot rely on any stable anchor 182 point to preserve connectivity. Nor they can rely on routing 183 mechanism that would be the source of overhead and instability. 185 2.2. Towards locator-independent network architectures 187 We distinguish network architectures based on their use of location 188 independent identifiers (or names) and locators for forwarding. 190 *Locator-based architectures* 192 As mentioned earlier, IP architectures are typically operated based 193 on locators corresponding to the IP addresses of the host interfaces 194 in their respective network attachment, used also as session 195 identifiers. This results in a complex mobility architecture built 196 on top, involving traffic anchors and tunnels to preserve the 197 identifier exposed to the transport layer: IP/IP or GRE tunnels in 198 Mobile IP, and GTP tunnels in 3GPP architectures. 200 The limitations of locator-based schemes in terms of complexity, 201 overhead and efficiency are well-recognized and led to other 202 alternatives to be considered. 204 *Locator-ID separation architectures* 206 LISP [RFC6830] was the first proposal to distinguish between the 207 usage of IP addresses as locators or identifiers by explicitly 208 defining two namespaces, respectively used for endpoint 209 identification and forwarding. A mapping service is further used to 210 bind an identifiers to a given location, and updated after mobility. 211 From there, several approaches have been defined, either host-based 212 like SHIM6 [RFC5533] or HIP [RFC4423]), or network-based, like LISP 213 [RFC6830], ILSR, ILNP [RFC6740] or ILA [I-D.herbert-intarea-ila] to 214 cite a few. 216 An overview of these approaches and their use in mobility is 217 presented in {?I-D.bogineni-dmm-optimized-mobile-user-plane}}. 219 The main challenge consists in maintaining a (distributed) mapping 220 service at scale, including the synchronization of local caches 221 required for scalability and efficiency. 223 *ID-based architectures* 225 A third class of approaches exists that redefines IP communication 226 principles (i.e. network and transport layers) around location- 227 independent network identifiers of node/traffic. The interest of 228 such architectures is highlighted in [I-D.vonhugo-5gangip-ip-issues] 229 (referred to as ID-oriented Networking) for it removes the 230 limitations introduced by locators and simplifies the management of 231 mobility. The draft however question the possibility to realize such 232 an architecture where node status and mobility would not affect 233 routing table stability. 235 The work done around Information-Centric Networking (ICN) falls into 236 such class of approaches that we refer to as purely ID-based, also 237 known as name-based [I-D.irtf-icnrg-terminology], although as we will 238 see, mobility management often departs from this principle. 240 2.3. Information-Centric Networking (ICN) 242 ICN is a new networking paradigm centering network communication 243 around named data, rather that host location. Network operations are 244 driven by location-independent data names, rather than location 245 identifiers (IP addresses) to gracefully enable user-to-content 246 communication. 248 Although there exist a few proposals, they share the same set of core 249 principles, resulting in several advantages including a simplified 250 mobility management [RFC7476]. For clarify, this section we focus on 251 hICN [I-D.muscariello-intarea-hicn] an ICN implementation for IPv6. 253 2.4. Hybrid-ICN overview 255 Hybrid ICN (hICN) is an ICN architecture that defines integration of 256 ICN semantics within IPv6. The goal of hICN is to ease ICN insertion 257 in existing IP infrastructure by: 259 1. selective insertion of hICN capabilities in a few network nodes 260 at the edge (no need for pervasive fully hICN network 261 deployments); 263 2. guaranteed transparent interconnection with hICN-unaware IPv6 264 nodes, without using overlays; 266 3. minor modification to existing IP routers/endpoints; 268 4. re-use of existing IP control plane (e.g. for routing of IP 269 prefixes carrying ID-semantics) along with performing mobility 270 management and caching operations in forwarding plane; 272 5. fallback capability to tradition IP network/transport layer. 274 hICN architecture is described in [I-D.muscariello-intarea-hicn]. 276 3. Hybrid-ICN Anchorless Mobility Management (hICN-AMM) 278 hICN, together with MAP-Me [I-D.irtf-icnrg-mapme], forms the basis 279 for the mobility management architecture we describe in the rest of 280 this document. Due to the pull based nature of hICN architecture, we 281 distinguish consumer and producer nodes, for which mobility is 282 handled differently 284 3.1. Consumer mobility in hICN 286 The consumer end-point is the logical communication termination that 287 receives data. Due to the pull-based and connection-less properties 288 of hICN communications, consumer mobility comes natively with ICN. 289 It is indeed sufficient that the consumer reissues pending interests 290 from the new point-of-attachment to continue the communication. 291 Consumer mobility is anchorless by design, and managed without any 292 impact on the transport session. It is however necessary to have an 293 appropriate transport layer on top able to cope with eventual 294 disruptions and path variations caused by the mobility event. 296 4. Producer mobility architectures 298 The producer end-point is the logical communication termination that 299 sends data. Producer mobility is not natively supported by the 300 architecture, rather handled in different ways according to the 301 selected producer mobility management scheme, some of which diverge 302 from the concept of pure ID-based architecture through their use of 303 locators. Additional procedures have to be performed to maintain 304 reachability as it moves in the network. 306 In fact, many schemes proposed for ICN are adaptations to the vast 307 amount of work made in IP over the last two decades [RFC6301]. 308 Surveys for the ICN family, resp. for CCN/NDN-specific solutions, are 309 available in [SURVEYICN], respectively [SURVEY1] and [SURVEY2]. 310 There has been however a recent trend towards anchorless mobility 311 management, facilitated by ICN design principles, that has led to new 312 proposals and an extension of previous classifications in 313 [I-D.irtf-icnrg-mapme] and [MAPME] to the four following categories: 315 * _Resolution based_ solutions rely on dedicated rendez-vous nodes 316 (similar to DNS) which map content names into routable location 317 identifiers. To maintain this mapping updated, the producer 318 signals every movement to the mapping system. Once the resolution 319 is performed, packets can be correctly routed directly to the 320 producer. 322 * _Anchor-based_ proposals are inspired by Mobile IP, and maintain a 323 mapping at network-layer by using a stable home address advertised 324 by a rendez-vous node, or anchor. This acts as a relay, 325 forwarding through tunneling both interests to the producer, and 326 data packets coming back. 328 * _Tracing-based_ solutions allow the mobile node to create a hop- 329 by-hop forwarding reverse path from its RV back to itself by 330 propagating and keeping alive traces stored by all involved 331 routers. Forwarding to the new location is enabled without 332 tunneling. 334 * _Anchorless_ approaches allow the mobile nodes to advertise their 335 mobility to the network without requiring any specific node to act 336 as a rendez-vous point. 338 4.1. Producer mobility in hICN 340 In an hICN network, regular routing protocols such as BGP, ISIS or 341 OSPF can be used for propagating all prefix announcements and 342 populate routers' FIBs. However, these protocols are not appropriate 343 and should not be used to manage name prefix mobility, for 344 scalability and consistency reasons. 346 The default mobility management for hICN is designed following the 347 same principles and protocols as MAP-Me, an anchorless producer 348 mobility management protocol initially proposed for ICN 349 [I-D.irtf-icnrg-mapme] [MAPME]. It builds on an initial forwarding 350 state bootstrapped by the routing protocol, and performs a 351 lightweight path repair process as the producer moves. For 352 simplicity, we refer to it as simply MAP-Me in the rest of the 353 document. 355 In the rest of this section, we describe the specific realization of 356 the protocol in an hICN context. Additional background and details 357 are available in [I-D.irtf-icnrg-mapme] and [MAPME]. The solution is 358 based on a path repair mechanism following mobility events, using 359 dynamic FIB updates. Using data plane mechanisms for ensuring 360 connectivity has been previously proposed in [DATAPLANE] to handle 361 link failures, and has been proven more reactive than relying on 362 typical control plane messaging. 364 5. Protocol description 365 5.1. Signalization messages; acknowledgements and retransmission 367 Signalization messages follow hICN design principles and use data 368 plane packets for signalization. Signalization messages and 369 acknowledgement are respectively Interest and Data packet (requests 370 and replies) according to hICN terminology 371 [I-D.muscariello-intarea-hicn]. Upon processing of those 372 advertisements, the network will send an acknowledgement back to the 373 producer using the name prefix as the source and the locator of the 374 producer as the destination, plus the sequence number allowing the 375 producer to match which update has been acknowledged. 377 Pending signalization interests that are not acknowledged are 378 retransmitted after a given timeout. 380 5.2. Dynamic face creation and producer-triggered advertisements 382 The producer is responsible for mobility updates and should be hICN- 383 enabled. It stores a sequence number incremented at each mobility 384 event. 386 Faces in the producer are assumed synchronized with layer 2 387 adjacencies, upon joining a new point-of-attachment, a new face 388 should be created. Face creation will trigger the increase of the 389 sequence number, and per-prefix advertisement packets to be sent to 390 the joined network. 392 Those advertisements should contain: 394 * the name prefix as the destination address, plus a field 395 indicating the associated prefix length; 397 * the locator of the producer as the source address, that will serve 398 for receiving acknowledgements; 400 * a sequence number sequentially increased by the producer after 401 each movement; 403 * a security token (see Section 7.2). 405 Upon producer departures from a PoA, the corresponding face is 406 destroyed. If this leads to the removal of the last next hop, then 407 faces that were previously saved are restored in FIB to preserve the 408 original forwarding tree and thus global connectivity. 410 5.3. Update protocol 412 Based on the information transmitted in the packet, and its local the 413 network's local policy, the network might decide to update its 414 forwarding state to reflect this change. 416 The update process consists in updating a few routers on the path 417 between the new and a former point-of-attachment. More precisely, 418 this is done in a purely anchorless fashion by sending a signalling 419 message from the new location towards the name prefix itself. This 420 packet will be forwarded based on the now-stale FIB entries, and will 421 update forwarding entries to point to the ingress interfaces of each 422 traversed router. 424 5.3.1. Illustration 426 {fig-mapme-update}} illustrates the situation of a P moving between 427 access routers AR1 and AR2 while serving user requests: 429 1. A first interest towards the producer originates from remote. 430 The producer answers with a Data packet. 432 2. Following this, the producer detaches from AR1 and moves to AR2. 434 3. As soon as it is attached to AR2, the producer sends an Interest 435 Update towards its own prefix, which is forwarded from AR2 436 following the FIB towards AR1 (one of its former positions in the 437 general case). 439 4. At each hop, the message fixes the FIB to point towards the 440 ingress face, until the message cannot be further forwarded in 441 AR1. 443 5. A subsequent message from remote will follow the updated FIB and 444 correctly reach the producer's new location in AR2. 446 P (radio link) AR1 AR2 GW Internet 447 | | | | | 448 1 | | | |<~~~~~~~~~~~~~| 449 | |<~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~| Interest | 450 |<~~~~~~~~~~~~~~| | | | 451 |-------------->| | | | 452 2 [] Data |---------------|-------------->| | 453 / | | | |------------->| 454 | |(attach to AR2)| | | | 455 -X]...............|...............| | | 456 3 |===============|==============>o FIB update | | 457 | Update | |==============>o FIB update | 458 4 | o<==============|===============| | 459 | FIB update | | | | 460 5 | | | |<~~~~~~~~~~~~~| 461 | | |<~~~~~~~~~~~~~~| | 462 |<~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~| | | 463 |---------------|-------------->| | | 464 | | |-------------->| | 465 | | | |------------->| 466 | | | | | 468 Figure 1: Signalization during producer mobility (MAP-Me) 470 Through this process, MAP-Me trades-off path optimality for a fast, 471 lightweight and loop-free forwarding update. It has been shown in 472 [MAPME] that stretch is bounded and typically kept low in scenarios 473 of interest. This results from the fact that MAP-Me operations 474 preserve the initial structure of the forwarding tree/DAG (direct 475 acyclic graph), by only flipping its edges toward the new producer 476 location. 478 MAP-Me does not perform a routing update. The protocol is 479 complementary to the routing protocol in that it can run in between 480 routing updates to handle producer mobility, at a faster timescale, 481 and with a lower overhead. Routing updates can be performed at a 482 lower-pace, to re-optimize routes once a node has relocated for 483 instance. 485 5.3.2. Message content 487 The update messages should contain : 489 * the name prefix as the destination address, plus a field 490 indicating the associated prefix length; 492 * the locator of the producer as the source address, that will serve 493 for receiving acknowledgements; 495 * a sequence number sequentially increased by the producer after 496 each movement; 498 * an optional security token. 500 5.3.3. Processing at network routers 502 At the reception of advertisement/update packets, each router 503 performs a name-based Longest Prefix Match lookup in FIB to compare 504 sequence number from the received packet and from FIB}. According to 505 that comparison: 507 * if the packet carries a higher sequence number, the existing next 508 hops associated to the lower sequence number in FIB are used to 509 forward it further and temporarily stored to avoid loss of such 510 information before completion of the acknowledgement process. 512 * If the packet carries the same sequence number as in the FIB, its 513 originating face is added to the existing ones in FIB without 514 additional packet processing or propagation. This may occur in 515 presence of multiple forwarding paths. 517 * If the packet carries a lower sequence number than the one in the 518 FIB, FIB entry is not updated as it already stores 'fresher 519 information'. To advertise the latest update through the path 520 followed by the packet, this one is re-sent through the 521 originating face after having updated its sequence number with the 522 value stored in FIB. 524 5.4. Notifications and scoped discovery 526 The update protocol is responsible for reestablishing global 527 connectivity with minimal changes to the FIBs. In order to further 528 improve the reactivity of the scheme and better support QoS 529 constraints of latency-sensitive traffic, we propose an additional 530 mechanism named *Notifications*. It assumes hICN-enabled routers at 531 the edge, and the existence of links between access routers, which 532 are typically used for handover, and proposes to exploit them during 533 mobility events, or to delay updates when possible. 535 5.4.1. Notification processing 537 Upon receiving a valid advertisement, the point-of-attachment will 538 remember the presence of the producer, update its corresponding FIB 539 entry but send no update. Previous next hops should be saved and 540 restored upon face deletion so as to preserve the forwarding tree/DAG 541 structure. 543 The rationale is that during mobility events, the producer will move 544 access connected and neighbouring base stations. It will be then 545 sufficient to make a scoped discovery around the last position known 546 to forwarding to find the producer within a few hops. 548 5.4.2. Illustration 550 Figure 2 illustrate such as situation where an Interest is sent to 551 the producer before it had the time to complete the update. 553 P (radio link) AR1 AR2 GW Internet 554 | | | | | 555 1 | | | |<~~~~~~~~~~~~~| 556 | |<~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~| Interest | 557 |<~~~~~~~~~~~~~~| | | | 558 |-------------->| | | | 559 2 [].....Data.....-)---------------|-------------->| | 560 / | | | |------------->| 561 | |(attach to AR2)| | | | 562 -Y]...............|...............+ | | 563 3 | | | |<~~~~~~~~~~~~~| 564 4 | X--|<~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~| | 565 | | | | | 566 5 |===============|==============>o FIB update | | 567 | Notification | | | | 568 | |~~~~~~~~~~~~~~>| (scoped discovery) | 569 6 |<~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~| | | 570 7 |---------------|-------------->| | | 571 | |<--------------| | | 572 | |---------------|-------------->| | 573 | | | |------------->| 574 | | | | | 576 Figure 2: Scoped discovery during producer mobility 578 1. A first interest towards the producer originates from remote. 579 The producer answers with a Data packet. 581 2. Following this, the producer detaches from AR1 and moves to AR2. 583 3. A subsequent message from remote arrives before the update could 584 take place, and is thus forwarded to AR1. 586 4. AR1 has no valid face anymore towards the producer, and enters 587 discovery mode by broadcasting the interest to neighbours. 589 5. In the meantime, we assume the notification reaches AR2. 591 6. Because the producer is attached to AR2, the producer can be 592 directly reachable. Otherwise, AR2 would iterate the discovery 593 to neighbours only if it had more recent information about the 594 producer location than its predecessor (based on sequencing of 595 regular Interests and Interest Updates). 597 7. The Data packet follows the reverse path to the consumer as 598 usual. 600 6. Benefits 602 We now review the potential benefits of the general architecture we 603 have presented using features from the hICN data plane for supporting 604 consumer and producer mobility. 606 6.1. Overview 608 *Native mobility* : This mobility management process follows and 609 exploits hICN design principles. It makes producer mobility native 610 in the architecture by preserving all benefits of hICN even when 611 consumers and/or producers are moving. 613 *Anchorless mobility* : Such approach belongs to the category of pure 614 ID-based mobility management schemes whose objective is (i) to 615 overcome the limitations of traditional locator-based solutions like 616 Mobile IP (conf)using locators as identifiers and requiring tunnels, 617 and (ii) to remove the need for a global mapping system as the one 618 required by locator-identifier separation solutions. The result is a 619 fully anchorless solution both in the data plane and in the control 620 plane. 622 *Local and decentralized mobility management* : Mobility updates are 623 handled locally and the routers that are affected are those on path 624 between successive positions of the producer. In particular, remote 625 endpoints are not affected by the event. Mobility is managed in a 626 fully distributed manner and no third party is required. This does 627 not prevent any centralized control (as discussed in 628 [I-D.auge-dmm-hicn-mobility-deployment-options]), but makes the 629 network robust to disconnectivity events. 631 The next section will discuss more in depth the following advantages 633 6.2. Simplicity, scalability, efficiency 635 As emerges from the points raised in the previous section, consumer 636 mobility is transparently supported by an hICN network in virtue of 637 the pull-based model and the way the forwarding path works. After 638 moving, a consumer can just reissue pending interests once attached 639 to the new access router at layer 2, without requiring any more 640 information from L3 and above. This ensures a fast and simple 641 handover, which can be further enhanced through additional mechanisms 642 such as in-network caching. Consumer mobility is fully anchorless 643 with hICN, and does not incur any signalization nor tunneling 644 overhead. 646 This is particularly interesting considering that most mobile users 647 are consumers only (e.g. linear video distribution, or large scale 648 video conferencing where we typically have few presenters and most 649 users are simply consumers). 651 Another aspect of using the unifying hICN architecture in replacement 652 of the traditional tunnel-based mobile core is that it removes the 653 need to maintain state for consumers and producers which are not 654 mobile (eg. IoT sensors), or not currently moving. 656 6.3. Reduced latency through caching 658 While this is not strictly linked to mobility, we first illustrate 659 the benefits of caching content close to the edge to reduce user 660 latencies. This is particularly important for wireless networks such 661 as WiFi or LTE which have non-negligible latencies especially during 662 connection setup, or after an idle period. The characteristics of 663 those radio networks are thus of interest for the performance of the 664 mobility architecture as a whole. 666 The example in Figure 3 considers a mobile node that can move access 667 two accesses linked to Access Routers (AR) AR1 and AR2, both 668 connected to the Internet though a common gateway (GW). This same 669 setup will be later used to illustrate the flow of packets during 670 mobility events, eventually specializing AR into AP or eNB when it 671 makes more sense. 673 +-----+ .--. 674 _,--+ AR1 +--, .-~ ~-( )_ _ 675 +-----+ / +-----+ \ +----+ | ~-. +-----+ 676 | C += =+ GW +---+ Internet \--//--+ P | 677 +-----+ \_ +-----+ / +----+ \ .' +-----+ 678 '--+ AR2 +--' ~-.__________.-~ 679 +-----+ 681 Figure 3: Simple topology with a multi-homed consumer 683 We represent in Figure 4 a simple data flow between the different 684 entities involved in the communication between the mobile node M, and 685 a remote producer available over the Internet. 687 C AR1 AR2 GW Internet 688 | | | | | 689 1 |~~~~~~~~~~~~~~>| | | | 690 | Interest X |~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~>| | 691 | | | |~~~~~~~~~~~~~>| 692 | | | | ... 693 | | | |<-------------| 694 | Data X |<--------------|---------------| | 695 |<--------------| | | | 696 | | | | | 697 2 |~~~~~~~~~~~~~~>| | | | 698 3 | Interest Y |~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~>X Cache hit | 699 | |<--------------|---------------X | 700 |<--------------| | | | 701 | Data Y | | | | 703 LEGEND: 704 ~~~~>: Interest <---- Data ====> Signalization 705 ....-: L2 detach .....+ L2 attach X failure o event 707 Figure 4: Reduced latency through caching 709 Numbers on the left refer to the following comments relative to the 710 data flow: 712 1. The consumer issues a first interest towards name prefix X, which 713 is transported up to the producer. A Data packet comes back 714 following the reverse path and populating intermediate caches. 715 Latency of the exchange can be seen by the distance between lines 716 on the vertical axis. 718 2. The consumer now requests content B, which has previously been 719 requested by another consumer located on the same gateway. 720 Interest B thus hits the cache, refreshes the entry, and allows a 721 lower round-trip latency to content both for consumer C and any 722 subsequent request of the same content. 724 6.4. Improved reliability through caching 726 Mobile networks might consist in unreliable access technologies, such 727 as WiFi, responsible for packet losses. Figure 5 considers a similar 728 scenario with a lossy channel (eg. WiFi) between the mobile and the 729 first access router. 731 C (radio link) AR1 AR2 GW Internet 732 | | | | | 733 1 |~~~~~~~X | | | | 734 2 |~~~~~~~~~~~~~~>| | | | 735 | Interest |~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~>| | 736 | | | |~~~~~~~~~~~~~>| 737 | | | | ... 738 | | | |<-------------| 739 | Data |<--------------|---------------| | 740 3 | X-------| | | | 741 | | | | | 742 4 |~~~~~~~~~~~~~~>X Cache hit | | | 743 |<--------------X | | | 744 | | | | | 746 Figure 5: IU propagation example 748 1. The first issued interest is lost due to bad radio conditions. 750 2. Upon detection (either after a timeout, the consumer can just 751 reissue the lost Interest. 753 3. This time the remote producer successfully replies but the Data 754 packet is lost on the radio link. 756 4. Upon a similar detection, the consumer can reissue the lost 757 Interest that will hit a locally stored copy at the router where 758 the loss occurred (or again use a detection mechanism to 759 retransmit the Data packet). 761 6.5. Local mobility and recovery from common cache 763 The same mechanism can be used to recover from mobility losses after 764 the consumer reconnects to the new network as the content will 765 already be available in the cache at the junction router between the 766 two accesses. This is particularly interesting in case of micro- 767 mobility between access routers that are topologically close in the 768 network. 770 This is also the opportunity to manage those losses on behalf of the 771 transport protocol, so that only losses due to congestion are exposed 772 to it, and don't perturb the feedback loop by unnecessarily reducing 773 the transfer rate. 775 C (radio link) AR1 AR2 GW Internet 776 | | | | | 777 1 |~~~~~~~~~~~~~~>| | | | 778 | Interest |~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~>| | 779 | | | |~~~~~~~~~~~~~>| 780 |(detach fm AR1)| | | | 781 2 ..|...............- | |<-------------| 782 | |<--------------|---------------| | 783 3 | Data X-| | | | 784 | | | | | 785 |(attach to AR2 | | | | 786 4 ..|...............|...............+ | | 787 5 |~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~>| | | 788 6 | | |~~~~~~~~~~~~~~>X Cache hit | 789 | | |<--------------X | 790 |---------------|---------------| | | 791 | | | | | 793 Figure 6: IU propagation example 795 1. The consumer issues an interest before moving to a new location 797 2. It detaches from the first Access Router AR1 799 3. This causes the returning data packet to be lost as there is no 800 more a valid face towards the consumer. 802 4. The consumer has finished attachment to the new access router 803 AR2. 805 5. It can retransmit pending interests immediately. 807 6. The interests will hit the cache at the first junction point 808 between AR1 and AR2 which have previously seen the data packet 809 coming back. 811 6.6. Additional reliability through consumer multihoming 813 Because mobility is implemented at layer 3 and is thus agnostic to 814 the physical layer, this allows a mobile consumer to seamlessly 815 switch to a different access layer, eg. WiFi to LTE, following the 816 unreachability of the preferred radio access. 818 Figure 7 illustrates a fallback to LTE which can be performed 819 transparently for the application. 821 C WiFi GW LTE enB PGW Internet 822 | | | | | | 823 1 |~~~~~~~~~~~>| | | | | 824 | |~~~~~~~~~~~>| | | | 825 | | |~~~~~~~~~~~~|~~~~~~~~~~~~|~~~~~~~~~~~>| 826 | | | | | | 827 | | |<-----------|------------|------------| 828 | |<-----------| | | | 829 |<-----------| | | | | 830 2 | X | | | | 831 3 |~~~~~~~~~~~~X~~~~~~~~~~~~|~~~~~~~~~~~>| | | 832 | X | |~~~~~~~~~~~>| | 833 | X | | |~~~~~~~~~~~>| 834 | | | | | | 835 | | | | |<-----------| 836 | | | |<-----------| | 837 |<-----------|------------|------------| | | 838 4 |~~~~~~~~~~~>|... | | | | 839 | | | | | | 841 Figure 7 843 1. First interest is sent on the WiFi link. 845 2. WiFi unavailability due to failure for instance. 847 3. The application seamlessly switches to the LTE link. 849 4. Upon recovery, the traffic can be brought back on the WiFi 850 interface. 852 hICN handles consumer mobility from one access to the other (e.g. 853 WiFi to LTE or vice-versa) without any a-priori knowledge of the 854 multiple networks to use as it is the case of MPTCP or QUIC 855 approaches. Moving rate and congestion control at the receiver end 856 results to be a significant advantage w.r.t. all existing 857 alternatives in controlling dynamically multiple and new discovered 858 network accesses in presence of mobility. 860 This use case highlights the importance of having a compatible 861 transport, as the WiFi and LTE paths will have much different 862 characteristics in terms of delay, jitter and capacity. 864 Evaluations of the scheme have shown this scheme to preserve the 865 performance of flows like mobile video distribution up to very high 866 switching rates in the order of a second, not even considering 867 optimization occurring from network support. 869 Mobility is handled transparently at the network layer with very fast 870 handover times, due to the connection-less property of hICN. This 871 makes it possible to offer reliable WiFi connectivity, besides its 872 lossy nature as observed in previous use case and besides the 873 frequency of mobility from one network access to the other. 875 6.7. Bandwidth aggregation with consumer multihoming 877 Bandwidth aggregation can be realized dynamically through a 878 congestion-aware load-balancing forwarding strategy at the client, 879 with no a priori knowledge of paths. This is done similarly in the 880 network by hICN forwarders, allowing a combination of multi-homing, 881 multipath and multi-source data transfers. As all the paths are used 882 at the same time, hICN offers the full network capacity to the users 883 and tends to smooth fluctuations due to the radio channels. 885 Over an heterogeneous network access, hICN also offers a simple and 886 cost-effective realization of heterogeneous channel bonding allowing 887 an user to seamlessly roam across different radios or fixed lines 888 (for increased reliability or reduced costs), or aggregate their 889 bandwidth for high-throughput applications such as video streaming. 891 We illustrate a simplified data flows with one mobile consumer C 892 alternating interests between a WiFi and LTE access points. The load 893 balancing strategy would in that case optimize the split ratio 894 between the two access to realize an optimal split. Note that in 895 that case the relative distances on the vertical axis have not been 896 respected here for readability. 898 C WiFi GW LTE enB PGW Internet 899 | | | | | | 900 |~~~~~~~~~~~~|~~~~~~~~~~~~|~~~~~~~~~~~>| | | 901 |~~~~~~~~~~~>| | |~~~~~~~~~~~>|~~~~~~~~~~~>| 902 | |~~~~~~~~~~~>| | | | 903 | | |~~~~~~~~~~~~|~~~~~~~~~~~~|~~~~~~~~~~~>| 904 | | | | | | 905 | | | | |<-----------| 906 | | | |<-----------| | 907 |<-----------|------------|------------| | | 908 | | |<-----------|------------|------------| 909 | |<-----------| | | | 910 |<-----------| | | | | 911 | | | | | | 912 | | | | | | 914 Fine grained control from the application allows fully exploiting 915 available bandwidth, resulting in an aggregated throughput equal to 916 the sum of access throughputs, which is hard to achieve with existing 917 solutions. 919 6.8. Traffic and signalization offload 921 As a natural consequence of its anchorless behavior, an hICN network 922 can continue to operate in disconnected mode, for local mobility, 923 even though no upstream entity is available. 925 In order to illustrate this, we slightly extend the previous topology 926 in Figure 8 with an additional access network. To show that local 927 mobility induces no traffic on upstream links, we further assume a 928 failure on the link between the gateway (GW) and the Internet. 930 +-----+ 931 _,--+ AR1 +--, 932 +-----+ / +-----+ \ .-~~~-. 933 | P += \ .- ~ ~-( )_ _ 934 +-----+ \_ +-----+ +----+ | ~ -. 935 '--+ AR2 +-----+ GW +----X----+ Internet \ 936 +-----+ +----+ FAIL \ .' 937 / ~- . _____________ . -~ 938 +-----+ +-----+ / 939 | C +------+ AR3 +-' 940 +-----+ +-----+ 942 Figure 8: Access network disconnected from core 944 The data flow represented in Figure 9 illustrates the communication 945 between a consumer connected to AR3, and a mobile producer moving 946 from AR1 to AR2. 948 C P AR1 AR2 AR3 GW X Internet 949 | | | | | | X | 950 |~~~~~~~~~|~~~~~~~~~~|~~~~~~~~~~|~~~~~~~~~>| | X | 951 | | | | |~~~~~~~~~>| X | 952 | | |<~~~~~~~~~|~~~~~~~~~~|~~~~~~~~~~| X | 953 | |<~~~~~~~~~| | | | X | 954 | |--------->| | | | X | 955 | | |----------|----------|--------->| X | 956 | | | | |<---------| X | 957 |<--------|----------|----------|----------| | X | 958 | | | | | | X | 959 | |..........- | | | X | 960 | |..........|..........+ | | X | 961 | |==========|=========>o | | X NO | 962 | | Update | |==========|=========>o X TRAFFIC | 963 | | o<=========|==========|==========| X | 964 | | | | | | X | 965 |~~~~~~~~~|~~~~~~~~~~|~~~~~~~~~~|~~~~~~~~~>| | X | 966 | | | | |~~~~~~~~~>| X | 967 | | | |<~~~~~~~~~|~~~~~~~~~~| X | 968 | |<~~~~~~~~~|~~~~~~~~~~| | | X | 969 | |----------|--------->| | | X | 970 | | | |----------|--------->| X | 971 | | | | |<---------| X | 972 |<--------|----------|----------|----------| | X | 973 | | | | | | X | 975 Figure 9: Anchorless mobility in network disconnected from core 977 We see that both the data and the signalization remain local to the 978 zone where the mobility occurs, and that communications during 979 mobility are not affected by the failure of the link upstream. This 980 is a sign that the mobile core is not loaded with unnecessary 981 traffic, and that communications remain local, thus improving user 982 flow latencies. The offload of both data and signalization allows 983 reducing the cost of the infrastructure by increasing the diversity 984 of resources used at edge, mutualizing their capacity, and lower 985 requiring network and compute capacity in the mobile core. A direct 986 consequence is also a more robust and reliable network. 988 7. Implementation considerations 989 7.1. Interaction with non-hICN enabled routers 991 The realization of the architecture in a partial hICN deployment 992 where some routers are not extended to support hICN mechanisms 993 requires either to introduce additional functionalities or protocol 994 support, or to reuse existing protocols achieving similar objectives 995 (following hICN design). 997 One such example is the combination of ICMP redirect messages and 998 Neighbour Discovery Proxies (NDProxy), that partially realizes the 999 objectives of the update process: 1001 * ICMP packets do not include sequence numbers however they can be 1002 transported as part of the payload; verification is deferred to 1003 the next hICN node which should send the packet backwards in case 1004 of verification failure to fix the incorrect path update. 1006 * multipath is not supported in the pure-IP part of the network 1007 (which is the expected behaviour) 1009 Identified concerns might be about the unexpected use of such 1010 protocols, the lack of available implementation for NDProxy, and 1011 security aspect related to redirect messages. The latter shares the 1012 fate of source routing, which has long been advocated against, and 1013 has recently gained popularity within the SPRING context. A proper 1014 security scheme is certainly the right way to address this problem, 1015 and we believe the set of benefits that we have listed are worth 1016 reconsidering such aspects. 1018 7.2. Security considerations 1020 As indicated in previous sections, signalization messages transmitted 1021 across trust boundaries must be secured. The choice of the solution 1022 will intimately depend on the selected protocols. 1024 The use of ICMP packet might allow reusing existing security schemes 1025 such as AH headers [RFC4302], or SEND [RFC3971] (and its proxy 1026 extensions [RFC6496], [RFC5909]). 1028 Alternatively, [SEC] has reviewed standard approaches from the 1029 literature and proposes a fast, lightweight and distributed approach 1030 that can be applied to MAP-Me and fits its design principles. 1032 7.3. Discussion 1034 Both consumer and producer mobility support multiple paths, however 1035 the support of mobility for a multihomed producer, is left for future 1036 updates of the present document. 1038 Similarly, the proposed producer mobility solution is appropriate for 1039 the management of micro-mobility; its extension to multiple domains 1040 is out of scope. 1042 8. IANA Considerations 1044 This memo includes no request to IANA. 1046 9. References 1048 9.1. Normative References 1050 [RFC2275] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 1051 Access Control Model (VACM) for the Simple Network 1052 Management Protocol (SNMP)", RFC 2275, 1053 DOI 10.17487/RFC2275, January 1998, 1054 . 1056 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1057 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1058 DOI 10.17487/RFC3971, March 2005, 1059 . 1061 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1062 DOI 10.17487/RFC4302, December 2005, 1063 . 1065 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1066 (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May 1067 2006, . 1069 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1070 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1071 June 2009, . 1073 [RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing 1074 Neighbor Discovery Proxy: Problem Statement", RFC 5909, 1075 DOI 10.17487/RFC5909, July 2010, 1076 . 1078 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 1079 RFC 5944, DOI 10.17487/RFC5944, November 2010, 1080 . 1082 [RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", 1083 RFC 6115, DOI 10.17487/RFC6115, February 2011, 1084 . 1086 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 1087 Support in the Internet", RFC 6301, DOI 10.17487/RFC6301, 1088 July 2011, . 1090 [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- 1091 Martinez, "Secure Proxy ND Support for SEcure Neighbor 1092 Discovery (SEND)", RFC 6496, DOI 10.17487/RFC6496, 1093 February 2012, . 1095 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 1096 Protocol (ILNP) Architectural Description", RFC 6740, 1097 DOI 10.17487/RFC6740, November 2012, 1098 . 1100 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1101 Locator/ID Separation Protocol (LISP)", RFC 6830, 1102 DOI 10.17487/RFC6830, January 2013, 1103 . 1105 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1106 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1107 "Information-Centric Networking: Baseline Scenarios", 1108 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1109 . 1111 9.2. Informative References 1113 [DATAPLANE] 1114 J, ., A, ., A, ., B, ., M, ., and . S, "Ensuring 1115 connectivity via data plane mechanisms.", 2013. 1117 [I-D.auge-dmm-hicn-mobility-deployment-options] 1118 Auge, J., Carofiglio, G., Muscariello, L., and M. 1119 Papalini, "Anchorless mobility management through hICN 1120 (hICN-AMM): Deployment options", Work in Progress, 1121 Internet-Draft, draft-auge-dmm-hicn-mobility-deployment- 1122 options-03, 6 January 2020, . 1126 [I-D.herbert-intarea-ila] 1127 Herbert, T. and P. Lapukhov, "Identifier-locator 1128 addressing for IPv6", Work in Progress, Internet-Draft, 1129 draft-herbert-intarea-ila-01, 5 March 2018, 1130 . 1133 [I-D.irtf-icnrg-mapme] 1134 Auge, J., Carofiglio, G., Muscariello, L., and M. 1135 Papalini, "MAP-Me : Managing Anchorless Mobility in 1136 Content Centric Networking", Work in Progress, Internet- 1137 Draft, draft-irtf-icnrg-mapme-05, 9 June 2020, 1138 . 1141 [I-D.irtf-icnrg-terminology] 1142 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 1143 D., and C. Tschudin, "Information-Centric Networking 1144 (ICN): CCNx and NDN Terminology", Work in Progress, 1145 Internet-Draft, draft-irtf-icnrg-terminology-08, 17 1146 January 2020, . 1149 [I-D.muscariello-intarea-hicn] 1150 Muscariello, L., Carofiglio, G., Auge, J., Papalini, M., 1151 and M. Sardara, "Hybrid Information-Centric Networking", 1152 Work in Progress, Internet-Draft, draft-muscariello- 1153 intarea-hicn-04, 20 May 2020, . 1156 [I-D.vonhugo-5gangip-ip-issues] 1157 Hugo, D. and B. Sarikaya, "Review on issues in discussion 1158 of next generation converged networks (5G) from an IP 1159 point of view", Work in Progress, Internet-Draft, draft- 1160 vonhugo-5gangip-ip-issues-03, 13 March 2017, 1161 . 1164 [MAPME] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., 1165 Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less 1166 Producer Mobility in Content-Centric Networks", 1167 DOI 10.1109/tnsm.2018.2796720, IEEE Transactions on 1168 Network and Service Management Vol. 15, pp. 596-610, June 1169 2018, . 1171 [SEC] Compagno, A., Zeng, X., Muscariello, L., Carofiglio, G., 1172 and J. Auge, "Secure producer mobility in information- 1173 centric network", DOI 10.1145/3125719.3125725, Proceedings 1174 of the 4th ACM Conference on Information- 1175 Centric Networking, September 2017, 1176 . 1178 [SURVEY1] Zhang, Y., Afanasyev, A., Burke, J., and L. Zhang, "A 1179 survey of mobility support in Named Data Networking", 1180 DOI 10.1109/infcomw.2016.7562050, 2016 IEEE Conference on 1181 Computer Communications Workshops (INFOCOM WKSHPS), April 1182 2016, . 1184 [SURVEY2] Feng, B., Zhou, H., and Q. Xu, "Mobility support in Named 1185 Data Networking: a survey", DOI 10.1186/s13638-016-0715-0, 1186 EURASIP Journal on Wireless Communications and 1187 Networking Vol. 2016, September 2016, 1188 . 1190 [SURVEYICN] 1191 Tyson, G., Sastry, N., Rimac, I., Cuevas, R., and A. 1192 Mauthe, "A survey of mobility in information-centric 1193 networks", DOI 10.1145/2248361.2248363, Proceedings of the 1194 1st ACM workshop on Emerging Name-Oriented Mobile 1195 Networking Design - Architecture, Algorithms, and 1196 Applications - NoM '12, 2012, 1197 . 1199 [TS29.274] "3GPP Evolved Packet System (EPS); Evolved General Packet 1200 Radio Service (GPRS) Tunnelling Protocol for Control plane 1201 (GTPv2-C); Stage 3", n.d.. 1203 Authors' Addresses 1205 Jordan Auge 1206 Cisco Systems 1207 11, rue Camille Desmoulins 1208 92130 Issy-les-Moulineaux 1209 France 1211 Email: augjorda@cisco.com 1213 Giovanna Carofiglio 1214 Cisco Systems 1215 11, rue Camille Desmoulins 1216 92130 Issy-les-Moulineaux 1217 France 1219 Email: gcarofig@cisco.com 1221 Luca Muscariello 1222 Cisco Systems 1223 11, rue Camille Desmoulins 1224 92130 Issy-les-Moulineaux 1225 France 1227 Email: lumuscar@cisco.com 1229 Michele Papalini 1230 Cisco Systems 1231 11, rue Camille Desmoulins 1232 92130 Issy-les-Moulineaux 1233 France 1235 Email: micpapal@cisco.com