idnits 2.17.1 draft-azgin-icnrg-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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2123 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PMNDN' is defined on line 1120, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group A. Azgin 3 Internet-Draft R. Ravindran 4 Intended status: Informational Huawei Technologies 5 Expires: January 3, 2019 July 2, 2018 7 DMS: Dynamic Inter- and Intra-Domain Mobility Support Framework for 8 Information Centric Networking 9 draft-azgin-icnrg-mobility-00 11 Abstract 13 The objective of this proposal is to introduce a mobility support 14 framework for information centric networking (ICN) that is capable of 15 supporting dynamic mobility scenarios associated with both consumer 16 and producer applications, in a mobile device connected to a wireless 17 LAN or WAN point of attachment (PoA). Due to rapidly evolving user 18 trends that shift towards increased mobility and increased access to 19 mobile content delivery (as both content producer and consumer), it 20 is essential for an ICN architecture to offer active mobility support 21 to end hosts, and present them with varying degrees of quality of 22 experience. We enable this through the use of a network-driven 23 mobility support architecture, which operates in a distributed and 24 anchorless manner, and relies on late-binding and in--band signaling 25 with the use of forwarding labels. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 3, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Consumer Mobility . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Producer Mobility . . . . . . . . . . . . . . . . . . . . 4 65 3. Mobility Requirements . . . . . . . . . . . . . . . . . . . . 6 66 4. Design Components . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Mobility Service and Components . . . . . . . . . . . . . 7 68 4.2. Forwarding Label and Components . . . . . . . . . . . . . 8 69 4.3. Distributed Mobility Controller and Components . . . . . 9 70 5. DMS Protocol Design . . . . . . . . . . . . . . . . . . . . . 9 71 6. DMS Implementation . . . . . . . . . . . . . . . . . . . . . 11 72 6.1. Registration Phase . . . . . . . . . . . . . . . . . . . 11 73 6.1.1. Producer Mobility . . . . . . . . . . . . . . . . . . 11 74 6.1.2. Consumer Mobility . . . . . . . . . . . . . . . . . . 15 75 6.2. Content Delivery Phase . . . . . . . . . . . . . . . . . 16 76 6.3. Handover Phase . . . . . . . . . . . . . . . . . . . . . 18 77 6.3.1. Intra-domain Handover . . . . . . . . . . . . . . . . 18 78 6.3.1.1. Producer Mobility . . . . . . . . . . . . . . . . 18 79 6.3.1.2. Consumer Mobility . . . . . . . . . . . . . . . . 20 80 6.3.2. Inter-domain Handover . . . . . . . . . . . . . . . . 21 81 7. Design Discussions . . . . . . . . . . . . . . . . . . . . . 22 82 7.1. Storage Considerations . . . . . . . . . . . . . . . . . 22 83 7.2. Scalability Considerations . . . . . . . . . . . . . . . 23 84 7.3. Security Considerations . . . . . . . . . . . . . . . . . 23 85 7.3.1. Producer Flooding . . . . . . . . . . . . . . . . . . 24 86 7.3.2. Consumer Flooding . . . . . . . . . . . . . . . . . . 24 87 8. Informative References . . . . . . . . . . . . . . . . . . . 24 88 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 26 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 91 1. Introduction 93 Mobility support for information centric networking (ICN), with 94 specific emphasis on content-centric networking (CCN) [CCN], 95 continues to be a critical research area [MOB12] [MOB16] to ensure 96 its viability in diverse and dynamic networking environments, while 97 offering an acceptable quality of service (QoS) to mobile users as 98 good as or better than the current solutions. Default mobility 99 support in CCN is a best-effort service that relies on its pull-based 100 design using request-data primitives, with end hosts receiving 101 content objects after making a request for them by sending Interest 102 messages towards the source. In this design, consumer mobility is 103 handled reactively, as the consumer re-expresses interests by making 104 retransmission requests for the dropped (or undelivered) content 105 objects due to the host's mobility, with in-network caching helping 106 to speed up recovery, however, with no guarantees on service quality 107 such as packet loss or content delivery latency. 109 Support for producer mobility, on the other hand, is not included by 110 design, as the default approach to re-discover producer's location 111 after a handover would trigger a timeout-based broadcast storm, which 112 would be unrealistic in practical scenarios. For this reason, 113 multiple approaches have been proposed to offer such support 114 [KITE][FWLRP][ANCLS] and provide some guarantees for end user 115 experience, as the lack of it can create significant issues [NDNMS]. 116 These solutions have focused on handling producer mobility using 117 various designs: (i) an anchor based solution [KITE] with requests 118 being forwarded through network or application specific anchor 119 points, (ii) a network-driven locator-based solution that separates 120 persistent application and topological network identifier namespaces 121 while relying on the late-binding technique [FWLRP], and (iii) an 122 anchorless host-driven design [ANCLS] with the mobile node 123 responsible for notifying the network of its movements to trigger 124 temporary updates on data plane. Host or user entity (UE) driven 125 mobility mechanisms such as [KITE] and [ANCLS] offer poor support to 126 achieve a make-before-break solution, as the path correction in these 127 mechanisms is only possible after the UE attaches to the new PoA, 128 while network driven solution can proactively start forwarding the 129 Interests from the UE's old location to the new one immediately after 130 it learns about the UE's detachment process. 132 There are advantages and disadvantages to each of these earlier 133 solutions, however, to address the specific application needs by 134 offering performance guarantees to them in a scalable manner, we 135 believe a network-driven solution is needed [MAAS]. Furthermore, to 136 provide a complete mobility solution for ICN with similar performance 137 guarantees, we cannot rely on the default CCN architecture, as the 138 level of mobility support offered by CCN is minimal, at best. 139 Therefore, we need solutions that can offer performance guarantees in 140 regards to latency and throughput, regardless of the type of 141 application a host runs, be it consumer or producer. The 142 architecture we propose here achieves this objective by using a 143 comprehensive mobility framework that combines active producer 144 mobility support with active consumer mobility support. Proposed 145 approach takes advantage of locator-driven forwarding with the use of 146 forwarding label [I-D.ravi-icnrg-ccn-forwarding-label], which is an 147 optional hop-by-hop header carried within the Interest messages to 148 identify a topological name (i.e., a network domain, or a network 149 host). As a result, proposed approach can offer seamless mobility 150 support to end hosts. 152 2. Related Work 154 2.1. Consumer Mobility 156 Existing research on consumer mobility support for CCN/NDN is limited 157 due to its limited impact on the performance, as the default best- 158 effort approach considered for CCN/NDN can offer some limited 159 guarantees. Available research on consumer mobility can typically be 160 categorized as proactive solution or reactive solution. Proactive 161 approach can target upcoming mobility events to for instance cache 162 content at nearby locations for faster access to content, before the 163 handover takes place. On the other hand, reactive approach is 164 triggered after a handover takes place. Default CCN/NDN approach 165 falls in the latter category. 167 For instance, [MOBINDN] uses a centralized architecture to support 168 host mobility, which, during/after handover, updates forwarding table 169 entries corresponding to request namespaces to create a shorter 170 retransmission path for the consumer requests from the new point of 171 attachment to the old one. The approach considered in [CMOB16] uses 172 prediction on consumer location to detect handover events and 173 estimate its location at future time points. The approach also 174 predicts which Interest packets will be dropped during a handover, 175 and proactively cache Data packets associated with them at nearby 176 routers so as to reduce retrieval latency after a successful 177 handover. 179 Even though the existing approaches can offer faster access to Data 180 packets that can improve the perceived quality of experience, no 181 guarantees can be offered to ensure certain quality requirements are 182 met, as network support is limited. 184 2.2. Producer Mobility 186 To improve the performance associated with Producer mobility in NDN/ 187 CCN-based ICN architectures, various approaches have been proposed, 188 and these approaches can be grouped into three categories: 190 o First, we have anchor-based solutions [KITE], where requests are 191 forwarded through designated nodes (i.e., network or application 192 specific nodes) that keep a record of mobile node movements or 193 provide a path towards it. As path setup requires setting up and 194 maintaining traces within the network, such an approach can 195 introduce significant signaling and state overhead. Furthermore, 196 gradual updates may prevent support for seamless mobility and the 197 use of application-specific anchors can regularly lead to 198 excessive path stretches. 200 o Second, we have anchor-less mobility solutions [ANCLS], where the 201 mobile node is responsible for notifying the network of its 202 movements by, for instance, triggering temporary updates on data 203 plane. In [ANCLS], temporary FIB entries are created at the 204 routers to override the default forwarding strategy to forward 205 packets towards the mobile Producer. However, as the approach 206 relies on existing schemes to provide route updates and name 207 resolution, local updates triggered by mobile handovers 208 continually result in local routing churn, while the global 209 routing convergence creates more instability in the forwarding 210 paths. As the number of mobile hosts increases with increased 211 traffic rate, scalability and global routing convergence can be a 212 major concern. Furthermore, such an approach would require full 213 support from the network to temporarily override the existing FIB 214 entries, which may only be possible when appropriate security 215 mechanisms to handle such signaling are applied. In such case, 216 seamless mobility cannot be guaranteed. 218 o Third, we have late-binding approaches [MAAS], which relies on 219 splitting the application and network identifier namespaces, and 220 where dedicated nodes that keep track of mobile movements are used 221 to resolve content or device prefixes or identifiers to locators, 222 which are then used as forwarding label to forward the requests. 223 For instance, [MAAS] utilizes dedicated controllers in combination 224 with in-band signaling that takes advantage of Interest-Data 225 symmetric routing within each domain to handle name resolution 226 management. The local controllers can communicate with other 227 controllers (such as home controllers) to handle inter-domain 228 mobility. While this approach mitigates path stretch issue, it 229 does increase the signaling overhead due to mobile end points. 230 Furthermore, controllers can become a bottleneck as the failure of 231 a local controller would lead to either temporary disconnects or 232 increased overheads. Lastly, even though [MAAS] can support 233 seamless Producer mobility with minimal path stretch, it requires 234 architectural changes that can go beyond what might be considered 235 for [KITE] and [ANCLS] as incremental upgrades to support seamless 236 mobility. 238 3. Mobility Requirements 240 Locator identifier split can be considered as an important 241 requirement to handle mobility at the network layer [SEAML], which 242 can inherently be supported by the ICN architectures (such as 243 MobilityFirst [MFRST]) due to unique names assigned to each entity 244 and routing on names to resolve locations using a global name 245 resolution system along with delay tolerant networking (DTN) features 246 such as hop-by-hop forward and store, and late-binding, to achieve 247 seamless connectivity. There are some limitations to achieve these 248 objectives efficiently with the current IP through the use of 249 protocols based on Mobile IP, due to using IP address both as a 250 locator and as an identifier, triangular routing and the associated 251 control overhead [RFC6301]. 253 In CCN/NDN based architectures, using hierarchical identifiers for 254 routing cannot scale due to potentially explosive growth in 255 namespaces and the reduced aggregatability of these namespaces with 256 increased mobility, multi-homing, or resource replication [NCMP]. 257 Furthermore, practical problems such as name-suffix hole may arise 258 when names are used for network reachability. Routing scalability is 259 typically achieved by designing names with aggregatable property, 260 which is the case for IP today. However, having such feature in CCN/ 261 NDN would lead to relinquishing the persistency of names, as the 262 names would involve a topological component for scalability (which 263 also suggests resources to be renamed depending on, for instance, 264 network or business specs or characteristics). Furthermore, 265 overloading an identifier as a locator can lead to unstable routing 266 control and forwarding plane operations. 268 Locator identifier split in CCN/NDN therefore imposes splitting the 269 hierarchical namespace to support routable, persistent and human- 270 friendly names. In such case, names would be divided based on 271 application binding vs. advertised network entities in control plane 272 to improve the scalability of routing. For instance, persistent 273 identifiers, which would be used to create secure content objects, 274 can be published by multiple content distributers, where they would 275 then be mapped to different locators to resolve the content names to 276 specific infrastructure entities. The fundamental requirement with 277 this form of splitting is no different than that of MobilityFirst or 278 LISP [RFC6830], which is the requirement of a name resolution system 279 (NRS) to map the two namespaces. 281 In addition to the locator identifier split, we can summarize the 282 general requirements for CCN/NDN based architectures to support 283 efficient packet forwarding involving mobile hosts as follows: 285 o Forwarding scalability: The size for the forwarding tables should 286 be independent of the number of mobile entities and the level of 287 mobility experienced by these entities. This requirement can be 288 met by requiring to keep object state only at the edges (i.e., 289 gateways), and perform routing at the core network based on the 290 locator prefixes. 292 o Control overhead: Network updates triggered by mobility should be 293 local rather than global, and they should not affect the 294 convergence of routing/forwarding. This requirement can be met by 295 using a localized mobility controllers (within each domain/AS) 296 that is capable of resolving namespaces corresponding to mobile 297 entities using the corresponding home bindings. 299 o Intra- and Inter-session mobility: Mobility support architecture 300 should be capable of supporting both intra-session mobility (e.g., 301 changing access point or mobility service node during an active 302 communication instance) and inter-session mobility (e.g., 303 reconnecting after timeout or session expiry). We can support 304 inter-session mobility through reactive discovery by communicating 305 with a mobility controller associated with the mobile entity's 306 namespace (i.e., home mobility controller, to which the mobile is 307 registered globally for its namespace and which provides global 308 resolution on such registered namespaces) to request an update. 309 We can support intra-session mobility through active tracking of 310 the mobile entity's movements, for instance, using proactive 311 signaling by the mobile entity to trigger update at all the 312 related ICN forwarders along the reverse Data path signaling to 313 re-resolve the namespace for the mobile entity to the correct 314 locator. 316 o Mobility granularity: Since supporting mobility may incur 317 increased signaling and communication overhead, it should be 318 realizable as a service, on-demand and for a subset of the mobile 319 entities (e.g., hosts/namespaces subscribed to the mobility 320 service). Granularity for the mobility service can be further 321 adjusted with respect to the geographical span of mobility 322 support, and latency, etc. 324 4. Design Components 326 4.1. Mobility Service and Components 328 While the proposed solution can be applied to all Interest flows in a 329 mobile network, it can also be selectively enabled to only mobile 330 producers. For this, our architecture relies on the use of mobility 331 service for matching entities (such as hosts, service, or content 332 name prefixes). The presence of mobility service is identified using 333 one of the following approaches: (i) with the use of Mobility Service 334 flag carried within the Interest which can be set by the end hosts or 335 ICN-enabled point of attachments (default approach for our 336 architecture), (ii) by prepending the content name prefix with the 337 Mobility Service tag, or (iii) by provisioning traffic policy rules 338 at the ICN service routers to monitor for Interest flows with pre- 339 configured names matching a prefix of the Interest (or by checking 340 the Interest's attributes to distinguish flows requiring seamless 341 mobility support). If mobility service is enabled on a namespace, 342 DMS protocols are used on the received Interests or forwarded Data 343 packets to provide seamless mobility support for the matching flows. 344 If mobility service is not enabled, regular CCN/NDN processing logic 345 is used on the received Interests or Data packets, by going through 346 the default CS/PIT/FIB processing. 348 4.2. Forwarding Label and Components 350 To realize ID/locator split in CCN, we use the forwarding label (FL) 351 object that acts as a locator and provides the flexibility to forward 352 Interests on a name other than the one provided within the original 353 Interest, while allowing the ability to modify it on-the-fly 354 [I-D.ravi-icnrg-ccn-forwarding-label]. Proposed FL-object helps with 355 not only mobility but also with opportunistic routing, binding 356 Interests to services at a given location, and in-network computing, 357 thereby allowing for incremental enhancement over CCN to provide 358 richer and optimized service aware routing at the network edge. 360 FL objects are considered as container objects that include locator 361 identifier, service specific metadata (i.e., contextual information 362 on the application/service to help the network triggering appropriate 363 FL processing such as trust validation) and (optional) security 364 attributes for authentication. Locator identifier is considered as a 365 hierarchically structured topological name representing a domain, a 366 gateway, or host identifiers. 368 FL objects are inserted within the Interest either by the consuming 369 application (which may require a trust binding between the content 370 identifier or prefix and the locator identifier) or by the network 371 (which typically occur at the ingress service routers, if the 372 Interest satisfies an existing flow service profile). As an FL 373 object can be modified within the network (e.g., at domain 374 boundaries, network edges, etc.), it is considered as part of the 375 optional hop-by-hop header. In regards to processing of FL-object 376 carrying Interests, various options are available depending on 377 service profiles and trust relationships, e.g., locator identifier 378 preference (over content identifier), content identifier preference 379 (over locator identifier), locator identifier preference with swap, 380 or locator identifier ignore. 382 For efficient utility and processing of FL objects, a separate data 383 structure is introduced at the ICN nodes, referred as the Forwarding 384 Label Table (FLT), which carries locator/identifier cache mappings 385 for supported flows. Packet processing logic for the FLT 386 corresponding to mobile flows is similar to that of FIB, which 387 suggests longest prefix matching on the carried content identifiers 388 to extract the locator information, which is then used for exact 389 match on the FIB. Also note that, utilization of FL objects is not 390 limited to mobile flows, as they can also be used to provide fast 391 forwarding path such as off-path caching on supported flows. 393 4.3. Distributed Mobility Controller and Components 395 Distributed Mobility Controllers (DMCs) are localized service nodes 396 within domains to handle mobility support for subscribed or visiting 397 mobile entities. DMC nodes operate in a decentralized manner to 398 resolve content/host identifiers to locators. These nodes use a 399 Local Registration Database (LDB) to store name to locator mappings 400 retrieved through local registrations (e.g., for visiting mobile 401 entities) and/or remote registrations (e.g., for member mobile 402 entities). DMC nodes also communicate with other DMC nodes in 403 different domains, using Route Request (RREQ) and Route Response 404 (RRES) messages, to discover current locator information on mobile 405 entities. DMC nodes are also responsible for updating the service 406 points and gateway nodes within their domain for localized name-to- 407 locator mappings. 409 5. DMS Protocol Design 411 Leveraging ICN's name-based mobility, the proposed architecture 412 allows any meaningful space of the name hierarchy to be mobile. End 413 hosts enable this by actively registering the associated namespace to 414 the network, where the mobility service enabled by the provider 415 allows the entities in another domain under the namespace to be 416 accessible anywhere on the Internet. This motivates a scalable 417 mobility architecture. The proposed solution achieves this objective 418 by utilizing four essential building blocks: Distributed Mobility 419 Controllers (DMCs) to provide name-to-locator mappings and manage 420 control overhead, Forwarding Label Table (FLT)s, which are used by 421 the designated routers to control information flow in the network) to 422 address forwarding scalability, Forwarding Labels and Mobility Tags 423 to address inter- and intra-session mobility at different mobility 424 granularities. 426 Proposed architecture considers a basic networking hierarchy, which 427 consists of a given number of domains or Autonomous Systems (AS). 428 Each domain/AS is assigned a DMC carrying a domain designated prefix. 429 DMCs are responsible for mapping local and remote entity names to 430 domain/router identifiers. If the entity is local (which is the case 431 for intra-domain delivery), DMC resolves the names to ISRs, whereas, 432 if the entity is remote (which is the case for inter-domain 433 delivery), DMC maps the names to local domain's egress router 434 identifier. Each host is statically or dynamically assigned to a 435 designated DMC (also referred as Home-DMC), which stores up-to-date 436 resolution information regarding its users. 438 Assuming the use of hierarchical identifiers, each host is assigned a 439 unique identifier representing the association of a user to its home 440 network. The aggregate identifier (including network and host 441 identifiers) is only needed during Registration. Network identifier, 442 for an endpoint, is not considered a priori requirement to support 443 successful location discovery. Using an identifier, however, is the 444 preferred choice to minimize control overhead. 446 DMCs are assumed to have access to information directly related to 447 communication taking place within its domain (e.g., Home DMC or 448 locator associated with content published within the domain by 449 current registered hosts). Hence, no direct synchronization is 450 assumed to exist among the DMCs. Active domain information on 451 visiting hosts is flushed on a regular basis, as soon as the 452 registered host leave the domain under DMC's control, to minimize 453 access to outdated information. However, Remote-DMCs are allowed to 454 store information on Home-DMCs representing the visiting hosts for 455 longer periods to minimize overhead associated with the initial 456 discovery (i.e., an ISR requesting a mapping for a consumer residing 457 in Remote-DMC's domain on a previously hosted Producer's prefix, or 458 during decentralized discovery responding with information on Home- 459 DMC to a request from another domain's DMC). 461 In this architecture, forwarding labels are utilized to route packets 462 in a controlled manner. Forwarding label is similar to content 463 prefix in the sense that, when used, it provides sufficient 464 information on the next physical or logical hop. However, unlike a 465 content prefix, forwarding label is used as a dynamic tag within the 466 Interest that is regularly updated (at the service routers and 467 gateway points) along the path to content source. To support the use 468 of forwarding labels, at each service or edge router or PoA, we 469 utilize an FLT that carries the mappings corresponding to content 470 prefixes and forwarding addresses. 472 Since handling mobility with FLT and forwarding labels incurs 473 additional memory and computational costs, forwarding decisions based 474 on FLT are limited to traffic tagged as being part of the mobility 475 service, whereas for other traffic, default routing based on FIB is 476 used. Therefore, any mobile host that wishes to use the mobility 477 service indicates its intent during the registration by setting a 478 single-bit mobility service tag (MS-tag) contained within the 479 registration message. Consumers can also enable this tag along with 480 the mobile entity's unique name to invoke the mobility service, which 481 would help ISRs to differentiate between mobile and non-mobile 482 entities. In scenarios where the mobility service is not explicitly 483 defined, forwarding is strictly based on the core CCN/NDN policies. 484 Note that, the use of mobility service also allows the use of in- 485 network caching and look-up based on the available FIB entries. 487 6. DMS Implementation 489 In this section, we explain the general operations for the proposed 490 DMS architecture in regards to (i) how the namespaces are registered 491 for faster resolution and delivery, (ii) how the content is delivered 492 from/to mobile end hosts, and (iii) the operations involved during a 493 handover. 495 6.1. Registration Phase 497 6.1.1. Producer Mobility 498 +--------------+ 499 | | 500 | +----------+ | 501 +------------------> | | HomeDMC | | <-------------------+ 502 | | +----------+ | | 503 | Resolution | | Update | 504 | +--------------+ | 505 | HomeAS | 506 | (Producer) | 507 | | 508 +----------------------------+ +-----------------------------+ 509 | +-----+ | | | | 510 | | DMC | +------+ +------+ +---+--+ | 511 | +--+--+ +----> |EISR |-------> ||IISR | +----> | DMC | | 512 | ^ | +------+ +---+--+ | +------+ | 513 | | | | | | | | 514 | | | | | | | | 515 | | +--+---+ | | | | | 516 | +------+ ISR2 | | | | +---+--+ | 517 | +---+--+ | | +---> | ISR1 | | 518 | | | | +--+---+ | 519 | | | | | | 520 | +---+--+ | | +--+--+ | 521 | | PoA2 | | | | PoA1| | 522 | +---+--+ | | +--+--+ | 523 | | | | | | 524 | | | | | | 525 | +-----+----+ | | +----+-----+ | 526 | | Consumer | | | | Producer | | 527 | +----------+ | | +----------+ | 528 +----------------------------+ +-----------------------------+ 529 ConsumerAS CurrentAS 531 Figure 1: Basic view for the mobility support architecture 533 We start by assuming that the Producer publishes content under 534 namespace /Prefix, and the end hosts learn the minimum control name 535 space needed to interact with the access points (or PoAs) during 536 mobile attachment. Figure 1 illustrates the basic topology. Here, 537 ISRs can be considered as the service points for the end hosts 538 connected to PoA(s) under each. 540 Step(1): Registration Phase initiates with Producer sending a 541 Register (REG) message for its content, under namespace /Prefix, to 542 the current host domain's DMC (e.g., CurrentDMC). REG message 543 includes the complete identifier for the Producer's namespace, 544 including the bindings for it: /Prefix:/HomeAS/ProducerID, where 545 /HomeAS/ProducerID represents the home binding identifier for the 546 entity /Prefix, with /HomeAS representing the identifier for 547 Producer's home domain. Here, for instance, /ProducerID can be the 548 device identifier, and if the device itself is mobile then 549 /ProducerID can be considered as part of /Prefix, in which case 550 /HomeAS would be sufficient for the home binding. We place no 551 restriction on /Prefix as for it to be globally routable or not, as 552 it is resolved using the decentralized DMC-driven infrastructure. To 553 complete registration, Producer sends a REG message to its PoA (e.g., 554 PoA1) with the prefix /PoA1/REG used as a forwarding label, which is 555 then forwarded using the existing forwarding table (FIB/FLT) entries 556 towards CurrentDMC through PoA1 and its service point (e.g., ISR1). 557 Note that, Producer can also send the registration message directly 558 to DMC by using /DMC/REG (in which case, on-path nodes would decide 559 accordingly to register). After receiving the REG message, ISR1 also 560 updates the forwarding label by including its identifier within 561 packet header to inform CurrentDMC on the identity of the service 562 point (or ISR) associated with the Producer's to-be-registered 563 namespace. After CurrentDMC receives the REG message, if the MS-tag 564 is set within the request to indicate a request for mobility support, 565 CurrentDMC's local registration database (LDB) is updated with the 566 entry /Prefix::/ISR1::/HomeAS (through insertion of a new entry or 567 modification of an existing entry), where the third component 568 specifies the home domain for /Prefix. Here, FLT in the PoA or LDB 569 in the DMC by default require at least two inputs, corresponding to 570 the prefix and locator information. For the sake of presentation 571 here, we use double colon to separate these entries. Additionally, 572 if the MS-tag is set within the forwarded REG message, FLT tables at 573 the on-path POA1 and ISR1 are also updated by inserting the 574 corresponding mappings targeting /ProducerID at the PoA1, and /PoA1 575 at ISR1. Specifically, this is done by adding the entry 576 /Prefix::/Producer to FLT table at PoA1, and the entry /Prefix::/PoA1 577 to FLT table at ISR1, upon receiving the acknowledgement message from 578 CurrentDMC. 580 +--------------------------+ +--------------+ 581 | | | | 582 | +------+ | HREG | +----------+ | 583 | +-------+ DMC | | +--------> | | HomeDMC | | 584 | | +------+ | | +----------+ | 585 | | | | | 586 | | | +--------------+ 587 | | | HomeAS 588 | +--+--+ | + 589 | | ISR1| | | 590 | +--+--+ ^ | FREG | 591 | | | | ^ 592 | +--+--+ | REG | +--------+-------+ 593 | | PoA1| | | | | 594 | +--+--+ | | | +------------+ | 595 | | | | | | PreviousDMC| | 596 | | + | | +------------+ | 597 | +----+-----+ | | | 598 | | Producer | | | | 599 | +----------+ | | | 600 +--------------------------+ +----------------+ 601 CurrentAS PreviousAS 603 Figure 2: Registration for Producer mobility 605 Step(2): Proactive Update Phase initiates with CurrentDMC sending a 606 Route Update (RUPD) message to the ingress routers within CurrentAS 607 to update their FLT tables with the entry /Prefix::/ISR1 so that any 608 Interest received by the ingress nodes targeting the namespace 609 /Prefix can be immediately forwarded to ISR1. At the ingress 610 routers, in addition to proactive updates, we can also use reactive 611 updates, which would be triggered after (i) a first request arrival, 612 in which case the ingress router would make a request for the 613 forwarding information after receiving an Interest under namespace 614 /Prefix, for which no entry exists within the ingress router's 615 forwarding tables; or (ii) receiving a mobility update on data plane, 616 with information carried within returned Data packets. However, the 617 reactive update phase may require the initial traffic to be forwarded 618 to the CurrentDMC to minimize latency, which would act as a temporary 619 anchor, hence introduce additional overhead to keep track of entries 620 to avoid sending recurring route requests for the non-local 621 Producers. For this reason, by default, we limit DMC to function 622 specifically as a resolution server, rather than offering a 623 combination of resolution and anchor functionalities. 625 Step(3): Home Registration Phase initiates with CurrentDMC sending to 626 DMC within Producer's HomeAS (HomeDMC) a Home-Register (HREG) message 627 for /Prefix using the complete identifier information for the 628 Producer. We can use the following as the prefix for the HREG 629 message: /HomeAS/DMC/HREG, which assumes /DMC to be a globally shared 630 anycast identifier within a domain. After HomeDMC receives the HREG 631 message, it updates its LDB accordingly; (i) if an active entry is 632 found in HomeDMC's LDB for Producer, corresponding to a different 633 domain, the entry is updated to represent the domain change as 634 follows: /Prefix::/Remote:CurrentDomainID::/Remote:PreviousDomainID, 635 with the first component representing the mobile entity's namespace, 636 the second component pointing to /CurrentAS and the third component 637 pointing to the previous domain the Producer was visiting (e.g., 638 /PreviousAS). Additionally, HomeDMC sends a Flush-Register (FREG) 639 message to the PreviousDMC using the identifier /PreviousAS/DMC to 640 timeout the existing entries while re-directing on-the-fly traffic to 641 the current domain Producer is visiting; (ii) if no active entry is 642 found in HomeDMC's LDB for Producer, then HomeDMC's LDB is updated 643 with the entry /Prefix::/Remote:CurrentDomainID::/. 645 6.1.2. Consumer Mobility 647 We start by assuming that the Consumer is assigned a unique 648 identifier /ConsumerID. 650 Step(1): Upon connecting to a network, Consumer sends a local 651 registration request (LREG message) towards a matching entity as 652 assigned by the hosting domain to register at the point of attachment 653 (PoA2) or the service point (ISR2) using its identifier /ConsumerID 654 (which could be a device ID, or a set of service IDs if service level 655 mobility is requested) by requesting mobility service support from 656 the network. The ConsumerID is also appended to the Interest, but 657 its scope is limited only to the link between the consumer and the 658 PoA. 660 Step(2): Upon receiving the LREG message, PoA2 or ISR2 registers 661 /ConsumerID within its FLT to include information on the Consumer, 662 such as its identifier, interface identifier, and any associated 663 forwarding label. 665 +------------------------------------------+ 666 | | 667 | +-----+ +-------------+ | 668 | | ISR2| +---> | ConsumerDMC | | 669 | ^ +-----+ +-------------+ | 670 | | | | 671 | | +-----+ | 672 | LREG| | PoA2| | 673 | | +-----+ | 674 | | | | 675 | + | | 676 | +----------+ | 677 | | Consumer | | 678 | +----------+ | 679 +------------------------------------------+ 680 ConsumerAS 681 Figure 3: Registration for Consumer mobility 683 6.2. Content Delivery Phase 685 In this section, we present the default content delivery for the 686 proposed architecture in the case of no handover. 688 Step(1): Consumer starts Content Delivery Phase by sending an 689 Interest for /Prefix to its PoA (PoA2), while including its host 690 identifier /ConsumerID within the request. We assume the request is 691 a fresh request, with no existing entry within PIT or a matching 692 content within CS along the path towards the Producer. If one 693 exists, default CCN/NDN operations would take place (i.e., if PIT 694 entry exists, aggregate by including /ConsumerID, if content exists, 695 respond with it). We also assume PoA acts as the service point for 696 the end host with mobility service installed. 698 Step(2): PoA2 checks its CS and PIT to find a matching entry for 699 /Prefix, and finds no match. PoA2 creates an entry within its PIT 700 for the request to also include /ConsumerID. PoA2 forwards the 701 Interest to its service point (ISR2) after removing /ConsumerID. 702 After receiving the Interest, ISR2 performs a more detailed check 703 including searching for FLT (and, if necessary FIB) entries. If no 704 entry is found, ISR2 creates a Route-Request (RREQ) message with the 705 prefix /DMC/RREQ and sends it to its local DMC. Furthermore, ISR2 706 updates its local request waiting list (LRWL) for the request 707 messages it creates (similar to the PIT entries) to avoid 708 retransmitting the same request to its DMC. Any further Interests 709 targeting /Prefix are queued at ISR2 until a response to the first 710 RREQ message is received on the given namespace. 712 Step(3): After DMC receives the RREQ message, it searches for a 713 matching entry within its LDB. If an entry is found, request can be 714 unicast sent to the HomeDMC for /Prefix. Similarly, request message 715 can be forwarded to HomeDMC, if /Prefix includes a domain-specific 716 identifier. If no entry is found, and the received content name does 717 not identify the home binding, then the request would use the 718 decentralized DMC infrastructure to identify HomeDMC for /Prefix. 719 One approach would be to forward the RREQ message to all the other 720 DMCs. We can reduce the discovery overhead by using a controlled 721 name-based multicast, by grouping multiple requests into a single 722 Interest and forwarding the Interest domain by domain until a match 723 is found. However, in practice, we can expect such home mapping to 724 be provided at the time of request. Also, similar to how it was with 725 ISR2, DMC also implements a LRWL for the received RREQ messages, to 726 suppress discovery attempts associated with new requests targeting 727 the same namespace. 729 Step(4): After HomeDMC receives the RREQ message, a Route-Response 730 (RRES) message is created in response to the request with the mapping 731 /Prefix::/CurrentAS that identifies the current location for the 732 Producer. Note that, if the response message is forwarded along 733 trusted domains, such responses can also be cached within on-path 734 domains to improve discovery timeframe for future requests. 736 Step(5): After Consumer side DMC receives HomeDMC's RRES message to 737 its RREQ message, DMC first updates its LDB with the entry 738 /Prefix::/CurrentAS::/HomeAS, identifying the current location for 739 the Producer and its home domain. DMC also creates a Data packet in 740 response to the received RREQ messages and alerts any ISR nodes 741 indicated by the LRWL entry associated with /Prefix, before removing 742 any such entries. For the given scenario, DMC responds to ISR2's 743 RREQ message by creating a RRES message with the mapping 744 /Prefix::/CurrentAS::/ER1, by also including information on the 745 preferred egress point (ER1), to which the ISR2 needs to forward the 746 Interest messages. Note that, by default, such mapping information 747 may readily be available at the ISR nodes within their FIB. 749 Step(6): After ISR2 receives the RRES message corresponding to its 750 earlier request, ISR2 also updates its FLT with the following entry: 751 /Prefix::/CurrentAS, while updating its FIB with the entry 752 /CurrentAS::/ER1. ISR2 then clears its LRWL entry for /Prefix and 753 starts forwarding the matching Interests using the forwarding label 754 /ER1/CurrentAS (with first destination being /ER1 and final 755 destination residing in /CurrentAS). 757 Step(7): After ER1 receives an Interest carrying a forwarding label, 758 it extracts the forwarding label to determine the next hop. In the 759 current scenario, ER1 determines itself as the first destination, 760 checks for the next destination and identifies it as /CurrentAS. 761 Assuming that the ERs have already populated their FIBs with domain- 762 based mappings of /RemoteAS::/NextHop, ER1 can set the received 763 Interest's forwarding label to /NextHop/CurrentAS before forwarding 764 it to /NextHop. This process is repeated until the Interest is 765 received by the ingress router at CurrentAS. 767 Step(8): After the ingress router at CurrentAS receives the Interest, 768 it determines that the target for the received Interest resides 769 within its domain. Ingress router then uses its FLT to determine the 770 address for the ISR servicing the PoA connected to the Producer 771 hosting /Prefix. FLT-based lookup process is repeated at the service 772 point and point of attachment, until the Producer receives the 773 Interest, after which content delivery towards the Consumer can 774 proceed along the reverse path, using CCN/NDN's breadcrumb approach. 776 Step(9): After the content object arrives at the PoA2, it searches 777 for and extracts to PIT entry to determine (i) the consumer 778 identifier, if it exists, and (ii) the interface metrics. For the 779 case that the consumer identifier (/ConsumerID) exists, PoA2 performs 780 a lookup on the FLT to find the entry for /ConsumerID to validate the 781 interface information. For the default case, with no handover, 782 interface information within FLT entry would be equal to the 783 interface metric extracted from the PIT entry, thereby allowing the 784 content object to be forwarded using the default forwarding process. 786 6.3. Handover Phase 788 6.3.1. Intra-domain Handover 790 6.3.1.1. Producer Mobility 792 Producer performs a handover, and connects to PoA3. 794 +-------------------------------------------+ 795 | | 796 | +------+ | 797 | +-------+ DMC +-------+ | 798 | | +------+ | | 799 | | | | 800 | | | | 801 | | | | 802 | +--+--+ +---+--+ | 803 | | ISR1| | ISR3 | ^ | 804 | +--+--+ +---+--+ | | 805 | | | | | 806 | +--+--+ +---+--+ | | 807 | | PoA1| Handover | PoA3 | | REG | 808 | +-----+ +---------> +---+--+ | | 809 | | | | 810 | +----------+ | | | 811 | | Producer +-----+ + | 812 | +----------+ | 813 | | 814 +-------------------------------------------+ 815 CurrentAS 816 Figure 4: Producer handover 818 Step(1): After the Producer performs a handover from PoA1 to PoA3 819 serviced by different ISRs, Producer repeats the registration process 820 by sending a REG message to CurrentDMC, as explained earlier. After 821 the CurrentDMC receives the REG message, it looks up for a matching 822 entry in its LDB for /Prefix to determine an intra-domain handover, 823 from ISR1 to ISR3. CurrentDMC updates its LDB entry with 824 /Prefix::/ISR3::/HomeDMC and initiates a proactive mobility update by 825 sending a Route-Update (RUPD) message to the ingress points so that 826 these border routers update their FLT tables with the entry 827 /Prefix::/ISR3. CurrentDMC also creates an FREG message and sends it 828 to ISR1, which include information on the new service point for 829 /Prefix. 831 Step(2): After ingress routers receive the RUPD message, they update 832 their FLT tables to point to ISR3 for /Prefix and start forwarding 833 any matching Interest towards the new ISR associated with /Prefix, 834 ISR3. 836 Step(3): After ISR1 receives the FREG message for /Prefix, ISR1 837 updates its local FLT with the entry /Prefix::/ISR3 and forwards any 838 incoming Interest targeting this namespace to ISR3. Additionally, 839 ISR1 also starts a timer to flush out its local FLT entry 840 corresponding to /Prefix when the timer expires. ISR1 also forwards 841 the FREG message to PoA1, which flushes its FLT entry upon receiving. 842 Note that, even though PoA1 can timeout its FLT entry after a 843 handover notification from Producer, FREG allows confirmation from 844 CurrentDMC of a successful registration after handover. 846 6.3.1.2. Consumer Mobility 848 +------------------------------------------+ 849 | +-------------+ | 850 | +-> ConsumerDMC | | 851 | | +------^------+ | 852 | | | | 853 | | | | 854 | +--+--+ +---+------+ | 855 | | ISR2| | ISR4 | | 856 | +--+--+ +---+--+ ^ | 857 | | | | | 858 | +--+--+ +---+--+ | | 859 | | PoA2| | PoA4 | | | 860 | +-----+ +------+ | | 861 | +--^ | | 862 | | + | 863 | +----------+ | LREG | 864 | | Consumer | + | 865 | +----------+ | 866 | | 867 +------------------------------------------+ 868 ConsumerAS 869 Figure 5: Consumer handover 871 Consumer mobility requires a more proactive approach as the mobile 872 host is the one triggering the content request. 874 Step(1): As Consumer initiates a handover from PoA2 to PoA4, during 875 the handover signaling, PoA2 is informed of the next PoA (or the set 876 of candidate PoAs) for the Consumer. 878 Step(2): After being informed of the upcoming handover to PoA4, PoA2 879 updates the existing FLT entry for the Consumer corresponding to 880 /ConsumerID by setting the interface metric to a predefined value 881 corresponding to Not_Attached and initializing the forwarding label 882 entry to identifier corresponding to PoA4 (/PoA4). If the next PoA 883 information received from Consumer includes a list of candidate PoAs, 884 then the FLT entry would include multiple forwarding labels 885 corresponding to these PoAs (or a smaller subset of them). 887 Step(3): After the Consumer connects to PoA4, if the Consumer 888 requires mobility support from the network, it sends an LREG message 889 to PoA4 to register its host identifier (/ConsumerID) at the PoA 890 within its FLT. 892 Step(4): After Consumer's handover to PoA4, as content objects arrive 893 at PoA2, due to Consumer's earlier Interests sent before the 894 handover, PoA2 extracts the matching entry from its PIT and 895 determines the use of mobility support service by a requesting 896 Consumer, which is identified through its host identifier 897 /ConsumerID. PoA2 then uses /ConsumerID to extract the FLT entry and 898 determines the forwarding label associated with the requesting host. 899 PoA2 then creates a Push-Data (PSHD) type content object, which is a 900 special type of data packet that bypasses PIT lookups during packet 901 forwarding. PoA2 then performs FIB lookup on the extracted 902 forwarding label (/PoA4), inserts the label within the packet and 903 changes its type to PSHD before forwarding it to the next hop towards 904 PoA4. 906 Step(5): Intermediate nodes that receive the PSHD-type content 907 objects, skips CS/PIT processing, and performs FIB lookup on its 908 forwarding label to determine the outgoing interface before 909 forwarding it to the next hop as indicated by the FIB entry. The set 910 of nodes that do not have a corresponding PIT entry can also save 911 this Data packet in their content stores to benefit other consumers. 913 Step(6): As the PoA4 receives these PSHD-type content objects, they 914 are queued at its CS for later retrieval by the Consumer, if the 915 process relies on the Consumer to re-express Interests for these 916 content objects. If the received PSHD-type content objects include 917 host identifier, PoA4 can push these content objects to the Consumer 918 as soon as the Consumer finishes handover and successfully registers 919 at PoA4. To do that, PoA4 performs a lookup on the FLT to validate 920 the registration for the /ConsumerID, before forwarding towards the 921 interface as indicated by the corresponding FLT entry. 923 6.3.2. Inter-domain Handover 925 Step(1): After Producer moves to a new domain, NextAS, the Producer 926 initiates the registration phase by sending a new REG message 927 upstream towards NextDMC also triggering updates along the path to 928 NextDMC, including the PoA4 and ISR4. 930 Step(2): NextDMC sends a HREG message to HomeDMC through HomeAS, 931 while also sending a RUPD message to ingress points, which update 932 their FLT with the entry /Prefix::/ISR4. 934 Step(3): After HomeDMC receives the HREG message, it determines an 935 inter-domain handover for the Producer, and sends CurrentDMC an FREG 936 message with the prefix /CurrentAS:CurrentDMC/FREG. HomeDMC also 937 includes information on the current domain that Producer is attached 938 to CurrentDMC. 940 Step(4): After CurrentDMC receives the FREG message, it creates a 941 local-scope FREG message and sends it to ISR3. Next, CurrentDMC 942 sends a Route-Update-With-Timeout (RUPDT) message to ingress points 943 requiring them to update their FLT entry associated with /Prefix to 944 point to /NextAS during the FLT-timeout period. Anytime an ingress 945 point receives an Interest targeting /Prefix with the wrong 946 forwarding label during the FLT-timeout interval, the timeout 947 parameter is reset to its default value to ensure that any Consumer 948 thsat is not aware of a domain change is informed. 950 Step(4.1): The forwarding label for the incorrectly labeled Interest 951 is updated with the correct forwarding label, and the Interest's 952 Mobility-Update tag (MU-tag) is set to 1, before the Interest is 953 forwarded towards the nextAS. 955 Step(4.2): When Producer receives an Interest with a set MU-tag, 956 suggesting that the Consumer side is not aware of Producer's inter- 957 domain handover, it sets the MU-tag within the Data packet as well, 958 to inform the Consumer side of the inter-domain handover. 960 Step(4.3): When ISR2 receives a Data packet with set MU-tag, ISR2 re- 961 initiates the Discovery Phase by requesting a forced RUPD from its 962 DMC, which then communicates with HomeDMC to acquire the up-to-date 963 mapping associated with /Prefix. Another alternative to the above 964 approach is for the Producer to include domain information within its 965 Data packets, in response to an Interest with a set MU-tag. 967 7. Design Discussions 969 In this section, we address the basic design considerations of a 970 mobility support architecture in an ICN. 972 7.1. Storage Considerations 974 FIB represents both the strengths (i.e., flexible operation and on- 975 the-fly routing decisions) and the weaknesses (i.e., overhead) of a 976 CCN/NDN architecture, with greater perceived impact as the network 977 size and content availability increase. Specifically, ad hoc 978 operation allows for greater flexibility during routing, whereas, 979 increased storage requirements (with variable prefix names and 980 multiple entries per prefix) degrade the forwarding efficiency at 981 each CCN/NDN enabled router by increasing the processing latency 982 [SNDNF]. 984 FLT addresses some of these drawbacks by partitioning the information 985 required for end-to-end packet forwarding at different sections in 986 the network. For instance, prefix-to-locator mappings are stored at 987 the local databases (LDBs) within mainly the DMC nodes. However, 988 because of domain-based partitioning of these namespaces, the number 989 of entries stored at a given LDB is much smaller than what is 990 expected to be stored in the FIB of a CCN/NDN router. Here, ISRs are 991 only responsible for keeping entries of the active hosts they serve, 992 rather than keeping entries for the hosts being serviced by the other 993 routers. Ingress/egress points provide the backbone dependent 994 mappings and their perceived overhead is limited in the maximum of 995 the number of domains and the number of locally hosted Producers 996 within a domain. The intermediate routers, between ISRs and ingress/ 997 egress points, are only responsible for carrying the mappings 998 associated with next hop to reach them, hence not anymore observing 999 overhead proportional to the number of hosts being serviced along the 1000 downstream channel. As a result, with the proposed architecture, we 1001 expect noticeable improvement in the processing latency within the 1002 network to route packets between endpoints. Specifically, by 1003 forwarding Interests on the controller-managed locator driven 1004 address-space, rather than the highly variable prefix-space, lookup 1005 latency on a typical CCN/NDN router does not anymore depend on the 1006 prefix length. 1008 7.2. Scalability Considerations 1010 For the proposed architecture, another important concern is the 1011 performance of the controller node, which is expected to service the 1012 requests of the hosts associated with its domain (hosted consumers, 1013 or homed entities). A DMC carries prefix-to-domain mappings for the 1014 hosted consumers and remote producers and prefix-to-router mappings 1015 for the hosted producers. Note that prefix-to-domain mappings are 1016 updated at a much lower rate (inter-AS handover rate) than the rate 1017 associated with prefix-to-router mappings, which change at the intra- 1018 AS handover rate. 1020 7.3. Security Considerations 1022 There are various ways an attacker can exploit the possible 1023 vulnerabilities in our architecture by targeting the distributed 1024 controllers which can be considered as the entities responsible for 1025 managing (authorizing, registering, updating) prefix to locator 1026 mappings. For instance, by registering non-existing prefixes to the 1027 DMC as fake producers, or by requesting non-existing prefixes from 1028 the DMC as fake consumers, attackers can overload the controllers and 1029 limit access to legitimate requests. Following are some of the 1030 possible approaches that can be implemented in such cases to minimize 1031 the impact of flooding-driven attacks on the overall performance. 1033 7.3.1. Producer Flooding 1035 We assumes a producer to include certain information within the 1036 registration message to identify the producer's home network and 1037 authenticate the registered content. Hence, we can limit the scope 1038 of fake-producer attacks through authentication failure messages 1039 received from the home networks. After an authentication failure 1040 message is received by the host network's DMC, information on the 1041 fake-producer can be shared with the host network's ISRs, to prevent 1042 or reduce access to the matching user's registration requests. 1044 7.3.2. Consumer Flooding 1046 To prevent an attacker from hijacking the network by sending requests 1047 for non-existent prefixes, multiple approaches are possible. First, 1048 we can employ a threshold-based admission policy at the first point 1049 of entry for the incoming requests and limit the number of 1050 outstanding requests that await for the path update from the DMC. 1051 Our architecture already does this to some extent, by suppressing 1052 requests targeting the same entity (i.e., Producer) at the ISRs. 1053 Second, we can use an adaptive decision policy to enforce stricter 1054 threshold values at certain ISRs depending on the experienced 1055 overhead at the DMCs. Since the forwarding label in a request 1056 message includes information on the entry points, DMCs can aggregate 1057 the necessary statistics to quickly determine the problematic areas, 1058 and restrict access whenever needed. Third, by sending feedbacks to 1059 ISRs on problematic requests, attackers can be identified in a timely 1060 manner and the information on them can be shared with other ISRs 1061 within the same domain to limit the effectiveness of future attacks. 1063 8. Informative References 1065 [ANCLS] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., 1066 Pau, G., and X. Zeng, "Anchor-less Producer Mobility in 1067 ICN", ACM ICN 2015. 1069 [CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 1070 Briggs, N., and R. Braynard, "Networking Named Content", 1071 ACM CoNEXT, 2009. 1073 [CMOB16] Farahat, H. and H. Hassanein, "Supporting Consumer 1074 Mobility Using Proactive Caching in Named Data Networks", 1075 IEEE GLOBECOM 2016. 1077 [FWLRP] Azgin, A., Ravindran, R., and G. Wang, "A Scalable 1078 Mobility-Centric Architecture for Named Data Networking", 1079 IEEE ICCCN Scene Workshop, 2014. 1081 [I-D.ravi-icnrg-ccn-forwarding-label] 1082 Ravindran, R., Chakraborti, A., and A. Azgin, "Forwarding 1083 Label support in CCN Protocol", draft-ravi-icnrg-ccn- 1084 forwarding-label-02 (work in progress), March 2018. 1086 [KITE] Zhang, Y., Zhang, H., and L. Zhang, "Kite: A Mobility 1087 Support Scheme for NDN", NDN Technical Report-0020, 2014. 1089 [MAAS] Azgin, A., Ravindran, R., Chakraborti, A., and G. Wang, 1090 "Seamless Producer Mobility as a Service in Information 1091 Centric Networks", ACM ICN IC5G Workshop, 2016. 1093 [MFRST] Venkataramani, A., Kurose, J., Raychaudhuri, D., Nagaraja, 1094 K., Mao, M., and S. Banerjee, "MobilityFirst: A Mobility- 1095 centric and Trustworthy Internet Architecture", ACM 1096 SIGCOMM CCR, 2014. 1098 [MOB12] Tyson, G., Sastry, N., Rimac, I., Cuevas, R., and A. 1099 Mauthe, "A Survey of Mobility in Information-centric 1100 Networks: Challenges and Research Directions", ACM MobiHoc 1101 Workshop on Emerging Name-Oriented Mobile Network Design, 1102 2012. 1104 [MOB16] Zhang, Y., Afanasyev, A., Burke, J., and L. Zhang, "A 1105 Survey of Mobility Support in Named Data Networking", IEEE 1106 INFOCOM NOM Workshop, 2016. 1108 [MOBINDN] Zijian, Z., Xiaobin, T., Hebi, L., Zhifan, Z., and M. 1109 Dianbo, "MobiNDN: A Mobility Support Architecture for 1110 NDN", IEEE CCC 2014. 1112 [NCMP] Adhatarao, S., Chen, J., Arumaithurai, M., Fu, X., and K. 1113 Ramakrishnan, "Comparison of Naming Schema in ICN", IEEE 1114 LANMAN, 2016. 1116 [NDNMS] Azgin, A., Ravindran, R., and G. Wang, "Mobility Study for 1117 Named Data Networking in Wireless Access Networks", IEEE 1118 ICC 2014. 1120 [PMNDN] Gao, D., Rao, Y., Foh, C., Zhang, H., and A. Vasilakos, 1121 "PMNDN: Proxy Based Mobility Support Approach in Mobile 1122 NDN Environment", IEEE Transactions on Network and Service 1123 Management, Vol:14, Issue:1, 2017. 1125 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 1126 Support in the Internet", RFC 6301, DOI 10.17487/RFC6301, 1127 July 2011, . 1129 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1130 Locator/ID Separation Protocol (LISP)", RFC 6830, 1131 DOI 10.17487/RFC6830, January 2013, 1132 . 1134 [SEAML] Ravindran, R., Lo, S., Zhang, X., and G. Wang, "Supporting 1135 Seamless Mobility in Named Data Networking", IEEE ICC 1136 2012. 1138 [SNDNF] Yuan, H., Song, T., and P. Crowley, "Scalable NDN 1139 Forwarding: Concepts, Issues, and Principles", IEEE ICCCN 1140 2012. 1142 Appendix A. Additional Stuff 1144 This becomes an Appendix. 1146 Authors' Addresses 1148 Aytac Azgin 1149 Huawei Technologies 1150 Santa Clara, CA 95050 1151 USA 1153 Email: aytac.azgin@huawei.com 1155 Ravishankar Ravindran 1156 Huawei Technologies 1157 Santa Clara, CA 95050 1158 USA 1160 Email: ravi.ravindran@huawei.com