idnits 2.17.1 draft-azgin-icnrg-ni-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 a Security Considerations section. ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2016) is 2732 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 566, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3220 (Obsoleted by RFC 3344) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 5 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: May 4, 2017 October 31, 2016 7 Enabling Network Identifier (NI) in Information Centric Networks to 8 Support Optimized Forwarding 9 draft-azgin-icnrg-ni-00 11 Abstract 13 The objective of this proposal is to introduce the notion of network 14 identifier (NI) in the ICN architecture. This is in addition to the 15 existing names (i.e., content identifiers, CIs, or application 16 identifiers, AIs, in general) that are currently used for both naming 17 and routing/forwarding purposes. Network identifiers are needed 18 considering the requirements on future networking architectures such 19 as: (i) to support persistent names (or persistently named objects) 20 and large-scale and high-speed mobility of any network entity (i.e, 21 devices, services, and content), (ii) to accommodate different types 22 of Internet of Things (IoT) services, many of which require low- 23 latency performance, and enabling edge computing to support service 24 virtualization, which will require support for large scale migration 25 and replication of named resources, and (iii) to scale the ICN 26 architecture to future Internet scale considering the exponentially 27 increasing named entities. These considerations also require 28 enabling a network based name resolution service for efficient and 29 scalable routing. 31 In the current draft, we begin by highlighting the issues associated 32 with ICN networking when utilizing only the AIs, which include 33 persistently named content, services, and devices. Next we discuss 34 the function NI serves, and provide a discussion on the two current 35 NI-based proposals, along with their scope and functionalities. This 36 is with the objective of having a single NI construct for ICN that is 37 flexible enough to adapt to different networking contexts. 39 Requirements Language 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC 2119 [RFC2119]. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on May 4, 2017. 62 Copyright Notice 64 Copyright (c) 2016 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Application Identifier (AI) vs. Network Identifier (NI) in 81 ICN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 82 3. NI based ICN Forwarding . . . . . . . . . . . . . . . . . . . 6 83 3.1. Label based ICN forwarding . . . . . . . . . . . . . . . 6 84 3.2. Link-object based ICN forwarding . . . . . . . . . . . . 8 85 3.3. Link Object vs. Forwarding Label . . . . . . . . . . . . 8 86 4. Name Resolution System Considerations . . . . . . . . . . . . 9 87 5. Differences with respect to Existing IP-based Proposals . . . 10 88 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 90 6.2. Informative References . . . . . . . . . . . . . . . . . 11 91 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 94 1. Introduction 96 Information centric networking (ICN) is proposed as a future Internet 97 architecture to evolve the current host-centric design of Internet 98 towards a content-oriented one, where the named object becomes the 99 principle entity in networking. In doing so, contents, services, and 100 devices become disentangled from location allowing for efficient use 101 of the distributed in-network caches and compute resources with more 102 flexible and dynamic packet forwarding techniques. ICN is expected 103 to offer a scalable and secure networking solution to address many 104 challenges of the current IP architecture. Towards this, we propose 105 to formalize the notion of network identifier (NI) in ICN protocol, 106 that is separate from content name or application identifier (CI/AI, 107 or simply AI) used to both name resources and route user requests. 109 2. Application Identifier (AI) vs. Network Identifier (NI) in ICN 111 AI represent the names of service, content, or devices assigned by 112 the application providers or device manufacturers, and which can be 113 validated through appropriate security mechanisms. ICN should 114 provide flexibility in accommodating a broad set of identifiers, 115 within which the two well-known classes include hierarchical and flat 116 identifiers. While a hierarchical identifier provides contextual 117 richness for the names, a flat identifier offers a fixed predictable 118 overhead and variable security properties within a given context. 119 Today, this identifier set is already in the order of billions (with 120 hundreds of millions top-level domain names [VRSGN], and billions of 121 second-level domain names). As tens of billions of devices are 122 expected to join the network, this identifier set will be further 123 augmented with the corresponding data objects significantly expanding 124 its size. To decouple applications from the underlying network 125 dynamics, identifiers are expected to be persistent within the scope 126 of the application and its deployment. 128 NI provides a binding for the AI to the network, at a location and in 129 a topology relevant manner. NI is managed by the network provider to 130 name the routers, point of attachments, servers and end devices. In 131 addition to ICN names, in an overlay deployment, NI could assume 132 names of the underlay network as well, such as IP or Ethernet 133 addresses. The growth of the NI space is proportional to the rate of 134 growth of domain topology, the total number of AS, and the end points 135 (if they are managed by the network), hence, being much slower than 136 the rate of growth of the named resources in the AI space. Hence if 137 the objective is to limit the size of the forwarding table and scale 138 control plane, it is desirable to route requests on NIs, with the 139 mapping between AI and NI is achieved in a scalable manner using a 140 network based name resolution system. 142 Content-centric design used by ICN allows end hosts to make requests 143 using any type of name supported by the applications, including 144 hierarchical (human-readable or hash-based) identifiers (as 145 considered by CCN, NDN[CCN] for both the client application use and 146 the network use-for routing-), or fixed flat identifiers (as 147 considered by MobilityFirst[MFRST] in the network for routing). We 148 refer to an ICN architecture that supports any application naming 149 format (i.e., human-readable or flat) within the network for routing 150 as a non-restricted ICN architecture (as in CCN/NDN), whereas an ICN 151 architecture with a fixed naming format for routing within the 152 network as a restricted ICN architecture (as in MobilityFirst). 154 As packet forwarding in ICN utilizes names or identifiers (associated 155 with contents, hosts, or services) which are typically managed by 156 applications, thereby of persistent nature, using such names in 157 packet forwarding introduces the following list challenges in regards 158 to routing scalability and forwarding efficiency [NAMES]. 160 o Using AI for Routing/Forwarding: Overloading an identifier as a 161 locator can lead to unstable routing control and forwarding plane 162 operations, particularly when replication and mobility of content 163 or end points are taken into consideration. Applications 164 typically construct names and replicate contents or services to 165 optimize their delivery without any consideration towards network 166 scalability or efficiency. Hence name aggregation does not help 167 with scaling the routing and forwarding as originally imagined, 168 and the cost of this would be quite significant in real world 169 scenarios, as discussed in [NCMP]. Furthermore, it is also 170 observed in [QCMP] that, in certain scenarios (such as content 171 mobility), name-based forwarding approaches can operate more 172 efficiently, if used in conjunction with address-assisted schemes 173 such as DNS or anchor point based approaches like Mobile IP 174 [RFC3220]. Additionally, when names are used for network 175 reachability, more practical problems such as name-suffix hole may 176 arise, as the content requests are forwarded towards non-existent 177 caches [MDHT]. 179 o Routing/Forwarding Scalability: Routing scalability is typically 180 achieved by designing NIs with aggregate-able property, which is 181 the case for the current IP architecture. However, having such 182 feature in a non-restricted ICN architecture would lead to 183 relinquishing the persistency of the names, along with its 184 security binding such as trust, as the names would involve a 185 topological component for scalability, which can also suggest 186 resources to be renamed depending on, for instance, network or 187 business specs or characteristics. When content names or 188 application identifiers use a hierarchical identifier format, we 189 observe scalability problems in control and data plane operations 191 [SFWD]. Such problems are caused by various factors. For 192 instance, the explosive growth observed in namespaces can lead to 193 a similar growth in routing/forwarding information base or table 194 sizes [AFWD][SPIT][WPIT], even when namespace aggregation is 195 enabled, to significantly limit the forwarding efficiency and 196 forwarding capacity. If ICN routing with hierarchical naming is 197 the accepted form of naming, name-aggregation is highly unlikely 198 to achieve any practical scalability. This is because, naming 199 ontology and assignment typically consider application objectives 200 of contextualizing names, service and content placement and 201 replication to better suit the consumers' needs without 202 considering any network objectives on control and data plane 203 efficiency and scalability. 205 o Handling Mobility, Migration, and Replication: The impact of 206 namespace expansion on routing/forwarding performance is typically 207 exacerbated with content mobility, or the use of multi-homing and 208 resource replication due to diminished aggregate-ability [NCMP]. 209 The authors in [QCMP] concludes that, as more than 20% of end 210 hosts make more than 10 network address transitions every day, 211 thereby suggesting that mobility should be considered as the norm 212 rather than the exception. Furthermore, to achieve location 213 independent routing based on AIs, each mobility event associated 214 with a device or a popular content may trigger updates on up to 215 14% of Internet routers. 217 For the above reasons, restructuring the identifier to directly or 218 indirectly contain a globally routable component becomes an important 219 requirement, especially, to handle mobility at the network layer for 220 architectures that do not restrict names or identifiers to any 221 specific format. We can refer to such operation as the Application 222 and Network identifier split (where the NI represents the globally 223 routable component, and the AI represents the persistent name/ 224 identifier) which enables splitting of the namespace to support 225 routable, persistent, and human-friendly names or identifiers. In 226 such a framework, names would be divided accordingly, i.e., based on 227 application binding (offering persistent names) vs. advertised 228 network entities (in routing plane) to provide a more scalable 229 routing architecture. For instance, a persistent name or identifier 230 /Provider/Type/Name, which would be used to create secure content 231 objects, can be published by multiple content distributors, where it 232 would be mapped to different NIs, such as /Distributor/Region/Zone/ 233 Storage, to resolve content names or identifiers to specific 234 infrastructure entities. The fundamental requirements with this form 235 of splitting is no different than that of MobilityFirst [MFRST] or 236 LISP [RFC6830], which is the requirement of a network based name 237 resolution system to map the two namespaces. 239 So far, various approaches have been proposed to support the use of 240 NI in ICN-based networking architectures, depending on how this 241 information is structured and where it is placed within the Interest 242 (which may also determine the structuring of Data packets). Next, we 243 discuss these solutions by specifically focusing on label-based ICN 244 forwarding [FWLDR][FWLRP][MAAS] and ICN-based Map-and-Encap 245 [MPNCP][SNAMP] to provide a general guidance on the use of NI in 246 information centric networks. 248 3. NI based ICN Forwarding 250 AI based routing is a feasible solution within certain contexts such 251 as: (i) when resources are static and routing is limited to local 252 area networks or local domains, such as access networks within the 253 scalability considerations of the control and forwarding plane; (ii) 254 in ad hoc situations where AI can be combined with suitable suffix 255 filters to seek content of interest for the applications. 257 On the other hand, the use of NI becomes important in the following 258 situations: (i) when the Interest packet goes outside the local 259 domain, where routing on AI is optionally supported (i.e., routing 260 scalability and efficiency seeks precedence); (ii) when the Interest 261 enters a local domain, and the domain has specific knowledge of an NI 262 associated with the resource inside its domain. 264 With the above considerations, with respect to end-to-end networking, 265 NI is not a mandatory feature, but an optional one. However, as 266 significant amount of user traffic fetches resources outside the 267 requesting host's local domain, it becomes crucial to provide 268 architectural support for NI in an ICN protocol. So far, two 269 solutions for NI in ICN, overall with the same objectives but serving 270 different purposes, have been proposed. These include the 271 forwarding-label proposal [FWLDR] and the Link Object described in 272 [SNAMP]. We next summarize these proposals and discuss their 273 differences. 275 3.1. Label based ICN forwarding 277 Label-based ICN forwarding provides NI capability by encoding a 278 network address along with (optional) security binding attributes 279 within an Interest packet to guide it towards a content source (which 280 can be the Producer, a content repository or a cache). We refer to 281 this label as the forwarding label [FWLDR], which can be offered as 282 part of an ICN network service (such as a name resolution service 283 with ICN APIs to register and resolve names). For the forwarding 284 label, we have the following important considerations: (i) forwarding 285 label, if present in the Interest packet, takes precedence (over AI) 286 for routing, (ii) forwarding label is mutable in the sense that it 287 can be swapped or removed by intermediate network elements in the 288 network based on routing considerations within its domain. Here, 289 forwarding labels are not limited to only the ICN names, but, in an 290 overlay mode, they can also represent names from other transport 291 layers as well, for instance, an IP address or a MAC address. 293 Forwarding label consists of multiple components, with the NI 294 representing the locator information. Forwarding label is embedded 295 within the Interest message at the edge router or the end point 296 within certain trust considerations, if the namespace supports the 297 use of an NI to reach a specific destination. For security reasons, 298 edge routers can validate the label based on the trust context or 299 ignore any label inserted by an ICN forwarder at the end hosts, by 300 removing the inserted label if the forwarding on labels is not 301 supported, or by swapping it with a new one depending on the feedback 302 from the name resolution system. Such an approach requires no trust 303 relationship among different domains, as each domain is capable of 304 resolving content namespace to a target domain, and swapping the 305 received label with one to which its resolves. 307 Forwarding label support for a namespace can be offered at a global 308 scale (i.e., supported by all the domains) or a local scale 309 (supported by a subset of the existing domains). For instance, some 310 autonomous systems can prioritize forwarding solely based on the 311 content names (or offer limited support for label-based forwarding on 312 specific namespaces). In such case, forwarding labels can include 313 additional service tag (or information on the associated service, for 314 which the use of forwarding label might be supported in certain 315 domains, such as towards mobility service) for routing packets on the 316 supported domains. In doing so, we can strategically forward 317 requests over domains that support such service to provide more 318 deterministic service guarantees. 320 If forwarding label use is supported (or permitted) within a domain, 321 by default, forwarding label is given preference over content 322 identifiers for packet forwarding. In such case, to maximize the 323 forwarding efficiency, additional mapping tables can be implemented 324 at the edge or border ICN routers for quick longest-prefix matching 325 (LPM) lookup on content names to determine a (or the) matching 326 forwarding label(s), which can then be used by the router to perform 327 LPM lookup on the FIB. As forwarding label typically represents a 328 target domain or router, a single LPM lookup on the FIB may suffice 329 to find the outgoing interface for the received Interest. This state 330 can also be software-defined based on application requirements using 331 an SDN based control plane. 333 3.2. Link-object based ICN forwarding 335 ICN-based Map-and-Encap utilizes link objects, which include 336 information on how to retrieve content objects. For instance, link 337 objects can represent domains that host the content object, or 338 direction towards which the requests need to be forwarded to find a 339 matching content object. Link objects consist of two optional 340 headers: (i) a link header, which includes the potential directives 341 that can be used for forwarding and is signed by the Producer to 342 validate its authenticity during forwarding, and (ii) a delegation 343 header, which is used to represent the link choice utilized by the 344 previous forwarder. Since delegations may change at consecutive hops 345 depending on the view of forwarders' network state and forwarding 346 strategy, delegation header represents a variable component that can 347 be altered during packet forwarding. 349 The role of link objects is mainly for guidance, to provide global 350 routing support on locally defined or routable content identifiers. 351 Hence, if link objects are implemented, they are consulted by the ICN 352 enabled routers only when forwarding lookup on content identifiers 353 returns no match on the forwarding information base. 355 3.3. Link Object vs. Forwarding Label 357 Next we list the major differences between a link object and a 358 forwarding label. 360 o Link objects are set by the end host's forwarding daemon with 361 certain level of trust associated to it, restricting the link 362 component to be immutable during forwarding. Forwarding labels 363 are set by the ICN edge routers or the end-host applications, with 364 the ability of network based management during Interest 365 forwarding, allowing each domain to perform packet forwarding 366 according to its administrative and service policies. 368 o Forwarding label allows the use of trust association to bind AI to 369 the NI depending on the context associated with its use, whereas 370 for the link objects, trust relationship is established by 371 default. 373 o Another difference is related to the processing of forwarding 374 label and link objects at the ICN routers. Link object is 375 processed only if the router cannot find a matching FIB entry for 376 the content identifier. On the other hand, forwarding label is 377 processed before a content identifier, if its use is enabled. 379 o Forwarding label can be enabled as part of a service, limiting its 380 use to the supported namespaces and requiring its use whenever 381 supported. Link object is more of an application driven component 382 and network service agnostic, allowing the network to decide on 383 its use. 385 o Forwarding label can be considered as an enabler for faster packet 386 processing at the ICN routers and optimized routing to a content 387 source, whereas link object can be considered as a hint towards 388 where to find the content. Since it is processed after FIB lookup 389 on the content identifier fails, it typically leads to lower 390 computational and bandwidth efficiency. 392 o As a link object can encode multiple routing hints, it can direct 393 a request towards multiple identifier locations, giving an ICN 394 router the option to choose any one of them based on the router's 395 forwarding strategy. This selection is shared between consecutive 396 hosts, but not enforced, which may lead to non-optimal forwarding 397 paths. Forwarding label, on the other hand, is enforced 398 consistently at consecutive hops within a domain whenever its use 399 is supported. 401 4. Name Resolution System Considerations 403 To manage the AI to NI mapping, we need a name resolution system 404 (NRS). In addition to exposing APIs to application to register its 405 name to the NRS, it should also scale and work efficiently 406 considering the scale of named resources that need to be published, 407 resolved, removed, and updated at high frequency, for instance, 408 corresponding to high-speed mobility scenarios. 410 The following are the design choices for the NRS: 412 o Hierarchical System: Here, AI to NI mapping is managed by the 413 application providers, but similar to DNS, the service has to sync 414 its name reachability information with high level name resolvers. 415 NDNS is an example of such a system [NDNS]. This design is 416 typically suitable in cases when resources are static, rather than 417 for highly dynamic systems such as ICN, where replication and 418 mobility will be the norm. Also, such system has to scale to 419 resolve information objects in contrast to host resolution, which 420 represents the current use. 422 o Integrated/Flat System: Here, resolution service is integrated 423 within the ICN infrastructure, where the router contributes a part 424 of its compute and storage resources to enable this service. This 425 integration allows multiple ways of designing a generic name 426 resolution service, similar to the designs for Global Name 427 Resolution Service (GNRS) in MobilityFirst [GNS] [ASPC] [GNRS]. 429 o Distributed System: Compared to the flat system, this type of 430 architecture preserves the contextual nature of DNS, by using the 431 context in the name to identify a home controller, where 432 respective AI to NI mapping can be resolved. At the same time, 433 such a system removes the need for home controllers to sync up 434 with high level resolvers. For instance, /company/content-id 435 would be mapped with a resolver named /company/resolver-id. 437 5. Differences with respect to Existing IP-based Proposals 439 To address persistent identity, routing scalability, multihoming, and 440 mobility limitations of the current IP, various incremental solutions 441 have been proposed, among which identifier/locator split emerged as 442 the key solution to address these challenges [RFC4984]. Here, we 443 specifically focus on three of these solutions: (i) Host Identity 444 Protocol (HIP) [HIP], (ii) Identifier-Locator Network Protocol (ILNP) 445 [ILNP], and Locator/Identifier Seperation Protocol (LISP) [RFC6830]. 446 HIP and ILNP achieve ID/locator separation and binding at the host 447 level whereas LISP achieves that at the network level (i.e., at the 448 network edge using service routers). 450 In HIP, public cryptographic keys are used as host identifiers, which 451 provide the binding to higher layer protocols instead of IP addresses 452 [RFC7401]. ILNP divides IP namespace into two distinct namespaces of 453 identifiers and locators, each of which carrying distinct semantics 454 with identifier representing the non-topological name for the host 455 and locator representing the topologically bound name for the network 456 [RFC6740]. LISP is a map-and-encap type protocol, which achieves id/ 457 locator separation by defining (i) endpoint identifiers, which are 458 used for routing at the access network and which represent the IP 459 address for the host, and (ii) routing locators, which are used for 460 routing at the core and which represent the IP address for the egress 461 routers. 463 These protocols fundamentally differ from ICN's objective to define a 464 new network layer, where name based routing, location independent 465 caching, mobility, multihoming, and multi-path routing are the 466 integral features. More specifically, this draft proposes to enable 467 AI/NI binding as a network service to allow efficient routing of user 468 requests depending on the application context. 470 6. References 472 6.1. Normative References 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, 476 DOI 10.17487/RFC2119, March 1997, 477 . 479 6.2. Informative References 481 [AFWD] Yi, C., Afanasyev, A., Wang, L., Zhang, B., and L. Zhang, 482 "Adaptive Forwarding in Named Data Networking", ACM CCR, 483 Jul 2012. 485 [ASPC] Sharma, A., Tie, X., Uppal, H., Venkataramani, A., 486 Westbrook, D., and A. Yadav, "A Global Name Service for a 487 Highly Mobile Internetwork", ACM SIGGCOM, 2014. 489 [CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 490 Briggs, N., and R. Braynard, "Networking Named Content", 491 ACM CoNEXT, 2009. 493 [FWLDR] Ravindran, R., Chakraborti, A., and A. Azgin, "Forwarding 494 Label Support in CCN Protocol", draft-ravi-ccn-forwarding- 495 label-02, March, 2016. 497 [FWLRP] Azgin, A., Ravindran, R., and G. Wang, "A Scalable 498 Mobility-Centric Architecture for Named Data Networking", 499 IEEE ICCCN Scene Workshop, 2014. 501 [GNRS] Hu, Y., Yates, R., and D. Raychaudhuri, "A Hierarchically 502 Aggregated In-Network Global Name Resolution Service for 503 the Mobile Internet". 505 [GNS] Venkataramani, A., Sharma, A., Tie, X., Uppal, H., 506 Westbrook, D., Kurose, J., and D. Raychaudhuri, "Design 507 Requirements for a Global Name Service for a Mobility- 508 Centric, Trustworthy Internetwork", IEEE COMSNETS, 2013. 510 [HIP] Nikander, P., Gurtov, A., and T. Henderson, "Host identity 511 protocol (HIP): Connectivity, mobility, multi-homing, 512 security, and privacy over IPv4 and IPv6 networks", IEEE 513 Communications Surveys and Tutorials, pp: 186-204, 2010. 515 [ILNP] Atkinson, R., "An Overview of the Identifier-Locator 516 Network Protocol (ILNP)", Technical Report, University 517 College London, 2005. 519 [MAAS] Azgin, A., Ravindran, R., Chakraborti, A., and G. Wang, 520 "Seamless Producer Mobility as a Service in Information 521 Centric Networks", ACM ICN IC5G Workshop, 2016. 523 [MDHT] Liu, H., Foy, X., and D. Zhang, "A Multi-level DHT routing 524 Framework with Aggregation", ACM SIGCOMM ICN Workshop, 525 2012. 527 [MFRST] Venkataramani, A., Kurose, J., Raychaudhuri, D., Nagaraja, 528 K., Mao, M., and S. Banerjee, "MobilityFirst: A Mobility- 529 centric and Trustworthy Internet Architecture", ACM 530 SIGCOMM CCR, 2014. 532 [MPNCP] Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang, 533 "Map-and-Encap for Scaling NDN Routing", NDN Technical 534 Report, ndn-004-02, 2015. 536 [NAMES] Baid, A., Vu, T., and D. Raychaudhuri, "Comparing 537 Alternative Approaches for Networking of Named Objects in 538 the Future Internet", IEEE INFOCOM NOMEN Workshop, 2012. 540 [NCMP] Adhatarao, S., Chen, J., Arumaithurai, M., Fu, X., and K. 541 Ramakrishnan, "Comparison of Naming Schema in ICN", IEEE 542 LANMAN, 2016. 544 [NDNS] Afanasyev, A., "Addressing Operational Challenges in Named 545 Data Networking Through NDNS Distributed Database", 2013. 547 [QCMP] Gao, Z., Venkataramani, A., Kurose, J., and S. Heimlicher, 548 "Towards a Quantitative Comparison of Location-Independent 549 Network Architectures", ACM SIGCOMM, 2014. 551 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 552 DOI 10.17487/RFC2629, June 1999, 553 . 555 [RFC3220] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, 556 2002. 558 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 559 Text on Security Considerations", BCP 72, RFC 3552, 560 DOI 10.17487/RFC3552, July 2003, 561 . 563 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 564 Workshop on Routing and Addressing", RFC 4984, 2007. 566 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 567 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 568 DOI 10.17487/RFC5226, May 2008, 569 . 571 [RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network 572 Protocol (ILNP) Architectural Description", RFC 6740, 573 2012. 575 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 576 Locator/ID Separation Protocol (LISP)", RFC 6830, 2013. 578 [RFC7401] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 579 "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, 580 2015. 582 [SFWD] Yuan, H., Song, T., and P. Crowley, "Scalable NDN 583 Forwarding: Concepts, Issues and Principles", IEEE ICCCN, 584 2012. 586 [SNAMP] Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang, 587 "SNAMP: Secure Namespace Mapping to Scale NDN Forwarding", 588 IEEE Global Internet Symposium, 2015. 590 [SPIT] Yuan, H. and P. Crowley, "Scalable Pending Interest 591 Table Design: From Principles to Practice", IEEE INFOCOM, 592 2014. 594 [VRSGN] "Verisign Domain Name Industry Brief", July 2016. 596 [WPIT] Varvello, M., Perino, D., and L. Linguaglossa, "On the 597 Design and Implementation of a Wire-speed Pending Interest 598 Table", IEEE INFOCOM NOMEN Workshop, 2013. 600 Appendix A. Additional Stuff 602 This becomes an Appendix. 604 Authors' Addresses 606 Aytac Azgin 607 Huawei Technologies 608 Santa Clara, CA 95050 609 USA 611 Email: aytac.azgin@huawei.com 612 Ravishankar Ravindran 613 Huawei Technologies 614 Santa Clara, CA 95050 615 USA 617 Email: ravi.ravindran@huawei.com