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