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