idnits 2.17.1 draft-irtf-icnrg-nrs-requirements-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2021) is 1083 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-wood-icnrg-ccnxmanifests - is the name correct? == Outdated reference: A later version (-02) exists of draft-ravi-icnrg-ccn-forwarding-label-01 == Outdated reference: A later version (-05) exists of draft-irtf-icnrg-flic-01 == Outdated reference: A later version (-07) exists of draft-irtf-icnrg-nrsarch-considerations-05 == Outdated reference: A later version (-06) exists of draft-oran-icnrg-qosarch-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group J. Hong 3 Internet-Draft T. You 4 Intended status: Informational ETRI 5 Expires: October 13, 2021 L. Dong 6 C. Westphal 7 Futurewei Technologies Inc. 8 B. Ohlman 9 Ericsson 10 April 11, 2021 12 Design Considerations for Name Resolution Service in ICN 13 draft-irtf-icnrg-nrs-requirements-05 15 Abstract 17 This document provides the functionalities and design considerations 18 for a Name Resolution Service (NRS) in ICN. An NRS in ICN is to 19 translate an object name into some other information such as a 20 locator, another name, etc. for forwarding the object request. This 21 document is a product of the Information-Centric Networking Research 22 Group (ICNRG). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 13, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Name Resolution Service in ICN . . . . . . . . . . . . . . . 4 60 2.1. Explicit name resolution approach . . . . . . . . . . . . 4 61 2.2. Name-based routing approach . . . . . . . . . . . . . . . 4 62 2.3. Hybrid approach . . . . . . . . . . . . . . . . . . . . . 5 63 2.4. Comparisons of name resolution approaches . . . . . . . . 5 64 3. Functionalities of NRS in ICN . . . . . . . . . . . . . . . . 6 65 3.1. Support heterogeneous name types . . . . . . . . . . . . 6 66 3.2. Support producer mobility . . . . . . . . . . . . . . . . 7 67 3.3. Support scalable routing system . . . . . . . . . . . . . 9 68 3.4. Support off-path caching . . . . . . . . . . . . . . . . 9 69 3.5. Support nameless object . . . . . . . . . . . . . . . . . 10 70 3.6. Support manifest . . . . . . . . . . . . . . . . . . . . 10 71 3.7. Support metadata . . . . . . . . . . . . . . . . . . . . 11 72 4. Design considerations for NRS in ICN . . . . . . . . . . . . 11 73 4.1. Resolution response time . . . . . . . . . . . . . . . . 11 74 4.2. Response accuracy . . . . . . . . . . . . . . . . . . . . 11 75 4.3. Resolution guarantee . . . . . . . . . . . . . . . . . . 12 76 4.4. Resolution fairness . . . . . . . . . . . . . . . . . . . 12 77 4.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12 78 4.6. Manageability . . . . . . . . . . . . . . . . . . . . . . 13 79 4.7. Deployed system . . . . . . . . . . . . . . . . . . . . . 14 80 4.8. Fault tolerance . . . . . . . . . . . . . . . . . . . . . 14 81 4.9. Security and privacy . . . . . . . . . . . . . . . . . . 14 82 4.9.1. Confidentiality . . . . . . . . . . . . . . . . . . . 14 83 4.9.2. Authentication . . . . . . . . . . . . . . . . . . . 15 84 4.9.3. Integrity . . . . . . . . . . . . . . . . . . . . . . 15 85 4.9.4. Resiliency and availability . . . . . . . . . . . . . 15 86 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 92 9.2. Informative References . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 The current Internet is based upon a host-centric networking 98 paradigm, where hosts are uniquely identified with IP addresses and 99 communication is possible between any pair of hosts. Thus, 100 information in the current Internet is identified by the name of the 101 host (or server) where information is stored. In contrast to host- 102 centric networking, the primary communication objects in Information- 103 centric networking (ICN) are the named data objects (NDOs) and they 104 are uniquely identified by location-independent names. Thus, ICN 105 aims for the efficient dissemination and retrieval of NDOs at a 106 global scale, and has been identified and acknowledged as a promising 107 technology for a future Internet architecture to overcome the 108 limitations of the current Internet such as scalability and mobility 109 [Ahlgren] [Xylomenos]. ICN also has emerged as a candidate 110 architecture in the IoT environment since IoT focuses on data and 111 information [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2]. 113 Since naming data independently from its current location (where it 114 is stored) is a primary concept of ICN, how to find any NDO using a 115 location-independent name is one of the most important design 116 challenges in ICN. Such ICN routing may comprise three steps 117 [RFC7927]: 119 o Name resolution: matches/translates a content name to the locator 120 of content producer or source that can provide the content. 122 o Content request routing: routes the content request towards the 123 content's location either based on its name or locator. 125 o Content delivery: transfers the content to the requester. 127 Among the three steps of ICN routing, this document investigates only 128 the name resolution step which translates a content name to the 129 content locator. In addition, this document covers various possible 130 types of name resolution in ICN such as one name to another name, 131 name to locator, name to manifest, name to metadata, etc. 133 The focus of this document is a Name Resolution Service (NRS) itself 134 as a service or a system in ICN and it provides the functionalities 135 and the design considerations for an NRS in ICN as well as the 136 overview of the NRS approaches in ICN. On the other hand, its 137 companion document [NRSarch] describes considerations from the 138 perspective of ICN architecture and routing system when using an NRS 139 in ICN. 141 This document represents the consensus of the Information-Centric 142 Networking Research Group (ICNRG). It has been reviewed extensively 143 by the Research Group (RG) members who are actively involved in the 144 research and development of the technology covered by this document. 145 It is not an IETF product and is not a standard. 147 2. Name Resolution Service in ICN 149 A Name Resolution Service (NRS) in ICN is defined as the service that 150 provides the name resolution function for translating an object name 151 into some other information such as a locator, another name, 152 metadata, next hop info, etc. that is used for forwarding the object 153 request. In other words, an NRS is a service that can be provided by 154 the ICN infrastructure to help a consumer to reach a specific piece 155 of information (or named data object). The consumer provides an NRS 156 with a persistent name and the NRS returns a name or locator (or 157 potentially multiple names and locators) that can reach a current 158 instance of the requested object. 160 The name resolution is a necessary process in ICN routing although 161 the name resolution either can be separated from the content request 162 routing as an explicit process or can be integrated with the content 163 request routing as an implicit process. The former is referred as 164 explicit name resolution approach, the latter is referred as name- 165 based routing approach in this document. 167 2.1. Explicit name resolution approach 169 An NRS could take the explicit name resolution approach to return the 170 locators of the content to the client, which will be used by the 171 underlying network as the identifier to route the client's request to 172 one of the producers or to a copy of the content. There are several 173 ICN projects that use the explicit name resolution approach such as 174 DONA [Koponen], PURSUIT [PURSUIT], NetInf [SAIL], MobilityFirst [MF], 175 IDNet [Jung], etc. In addition, the explicit name resolution 176 approach has been allowed for 5G control planes [SA2-5GLAN]. 178 2.2. Name-based routing approach 180 An NRS could take the name-based routing approach, which integrates 181 the name resolution with the content request message routing as in 182 NDN [NDN]/CCNx [CCNx]. 184 In the case that the content request also specifies the reverse path, 185 as in NDN/CCNx, the name resolution mechanism also derives the 186 routing path for the data. This adds a requirement on the name 187 resolution service to propagate request in a way that is consistent 188 with the subsequent data forwarding. Namely, the request must select 189 a path for the data based upon finding a copy of the content, but 190 also properly delivering the data. 192 2.3. Hybrid approach 194 An NRS could also take hybrid approach. For instance, it can attempt 195 the name-based routing approach first. If this fails at a certain 196 router, the router can go back to the explicit name resolution 197 approach. The hybrid NRS approach also works the other way around by 198 performing explicit name resolution first to find locators of 199 routers. And then it can carry out the name-based routing approach 200 of the client's request. 202 A hybrid approach would combine name resolution over a subset of 203 routers on the path with some tunneling in between (say, across an 204 administrative domain) so that only a few of the nodes in the ICN 205 network perform name resolution in the name-based routing approach. 207 2.4. Comparisons of name resolution approaches 209 The following compares the explicit name resolution and the name- 210 based routing approaches for several aspects: 212 o Overhead due to the maintenance of the content location: The 213 content reachability is dynamic and includes new content being 214 cached or content being expired from a cache, content producer 215 mobility, etc. Maintaining a consistent view of the content 216 location across the network requires some overhead that differs 217 for the name resolution approaches. The name-based routing 218 approach may require flooding parts of the network for update 219 propagation. In the worst case, the name-based routing approach 220 may flood the whole network (but mitigating techniques may be used 221 to scope the flooding). However, the explicit name resolution 222 approach only requires updating propagation in part of the name 223 resolution system (which could be an overlay with a limited number 224 of nodes). 226 o Resolution capability: The explicit name resolution approach, if 227 designed and deployed with sufficient robustness, can offer at 228 least weak guarantees that resolution will succeed for any content 229 name in the network if it is registered to the name resolution 230 overlay. In the name-based routing approach, content resolution 231 depends on the flooding scope of the content names (i.e. content 232 publishing message and the resulting name-based routing tables). 233 For example, when a content is cached, the router may only notify 234 this information to its direct neighbors. Thus, only those 235 neighboring routers can build a named based entry for this cached 236 content. But if the neighboring routers continue to propagate 237 this information, the other nodes are able to direct to this 238 cached copy as well. 240 o Node failure impact: Nodes involved in the explicit name 241 resolution approach are the name resolution overlay servers (e.g. 242 Resolution Handlers in DONA), while the nodes involved in the 243 name-based routing approach are routers which route messages based 244 on the name-based routing tables (e.g. NDN routers). Node 245 failures in the explicit name resolution approach may cause some 246 content request routing to fail even though the content is 247 available. This problem does not exist in the name-based routing 248 approach because other alternative paths can be discovered to 249 bypass the failed ICN routers, given the assumption that the 250 network is still connected. 252 o Maintained databases: The storage usage for the explicit name 253 resolution approach is different from that of the name-based 254 routing approach. The explicit name resolution approach typically 255 needs to maintain two databases: name to locator mapping in the 256 name resolution overlay and routing tables in the routers on the 257 data forwarding plane. The name-based routing approach needs to 258 maintain only the name-based routing tables. 260 Additionally, some other intermediary step may be included in the 261 name resolution, namely the mapping of one name to other names, in 262 order to facilitate the retrieval of named content, by way of a 263 manifest [Westphal] [Mosko]. The manifest is resolved using one of 264 the two above approaches, and it may include further mapping of names 265 to content and location. The steps for name resolution then become: 266 first translate the manifest name into a location of a copy of the 267 manifest; the manifest includes further names of the content 268 components, and potentially locations for the content. The content 269 is then retrieved by using these names and/or location, potentially 270 resulting in additional name resolutions. 272 Thus, no matter which approach is taken by an NRS in ICN, the name 273 resolution is the essential function that shall be provided by the 274 ICN infrastructure. 276 3. Functionalities of NRS in ICN 278 This section presents the functionalities of an NRS in ICN. 280 3.1. Support heterogeneous name types 282 In ICN, a name is used to identify data object and is bound to it 283 [RFC7927]. ICN requires uniqueness and persistency of the name of 284 data object to ensure the reachability of the object within a certain 285 scope. There are heterogeneous approaches to designing ICN naming 286 schemes [Bari]. Ideally, a name can include any form of identifier, 287 which can be flat or hierarchical, and human readable or non- 288 readable. 290 Although there are diverse types of naming schemes proposed in 291 literature, they all need to provide basic functions for identifying 292 data object, supporting named data lookup and routing. An NRS may 293 combine the better aspects of different schemes. Basically, an NRS 294 should be able to support a generic naming schema so that it can 295 resolve any type of content name, irrespective of whether it is flat, 296 hierarchical, attribute-based or anything else. 298 In PURSUIT [PURSUIT], names are flat and the rendezvous functions are 299 defined for an NRS, which is implemented by a set of Rendezvous Nodes 300 (RNs), the Rendezvous Network (RENE). Thus, a name consists of a 301 sequence of scope IDs and a single rendezvous ID is routed by the RNs 302 in RENE. Thus, PURSUIT decouples name resolution and data routing, 303 where the NRS is performed by the RENE. 305 In MobilityFirst [MF], a name called a Global Unique IDentifier 306 (GUID) derived from a human-readable name via a global naming service 307 is a flat typed 160-bits string with self-certifying properties. 308 Thus, MobilityFirst defines a Global Name Resolution Service (GNRS) 309 which resolves GUIDs to network addresses and decouples name 310 resolution and data routing similarly to PURSUIT. 312 In NetInf [Dannewitz], information objects are named using ni-naming 313 [RFC6920], which consist of an authority part and digest part 314 (content hash). The ni names can be flat as the authority part is 315 optional. Thus, the NetInf architecture also includes a Name 316 Resolution System (NRS) which can be used to resolve ni-names to 317 addresses in an underlying routable network layer. 319 In NDN [NDN] and CCNx [CCNx], names are hierarchical and may be 320 similar to URLs. Each name component can be anything, including a 321 human-readable string or a hash value. NDN/CCNx adopts the name- 322 based routing approach. The NDN router forwards the request by doing 323 the longest-match lookup in the Forwarding Information Base (FIB) 324 based on the content name and the request is stored in the Pending 325 Interest Table (PIT). 327 3.2. Support producer mobility 329 ICN natively supports mobility management. Namely, consumer or 330 client mobility is handled by re-requesting the content in case the 331 mobility event (say, handover) occurred before receiving the 332 corresponding content from the network. Since ICN can ensure that 333 content reception continues without any disruption in ICN 334 applications, seamless mobility from the consumer's point of view can 335 be easily supported. 337 However, producer mobility does not emerge naturally from the ICN 338 forwarding model as does consumer mobility. If a producer moves into 339 a different network location or a different name domain, which is 340 assigned by another authoritative publisher, it would be difficult 341 for the mobility management to update RIB and FIB entries in ICN 342 routers with the new forwarding path in a very short time. 343 Therefore, various ICN architectures in the literature have proposed 344 to adopt an NRS to achieve the producer or publisher mobility, where 345 the NRS can be implemented in different ways such as rendezvous 346 points and/or overlay mapping systems. 348 In NDN [Zhang2], for producer mobility support, rendezvous mechanisms 349 have been proposed to build interests rendezvous (RV) with data 350 generated by a mobile producer (MP). This can be classified into two 351 approaches: chase mobile producer; and rendezvous data. Regarding MP 352 chasing, rendezvous acts as a mapping service that provides the 353 mapping from the name of the data produced by the MP to the name of 354 the MP's current point of attachment (PoA). Alternatively, the RV 355 serves as a home agent as in IP mobility support, so the RV enables 356 consumer's interest message to tunnel towards the MP at the PoA. 357 Regarding rendezvous data, the solution involves moving the data 358 produced by the MP to a data depot instead of forwarding interest 359 messages. Thus, a consumer's interest message can be forwarded to 360 stationary place as called data rendezvous, so it would either return 361 the data or fetch it using another mapping solution. Therefore, RV 362 or other mapping functions are in the role of an NRS in NDN. 364 In [Ravindran], forwarding-label (FL) object is referred to enable 365 identifier (ID) and locator (LID) namespaces to be split in ICN. 366 Generally, IDs are managed by applications, while locators are 367 managed by a network administrator, so that IDs are mapping to 368 heterogeneous name schemes and LIDs are mapping to the network 369 domains or to specific network elements. Thus, the proposed FL 370 object acts as a locator (LID) and provides the flexibility to 371 forward Interest messages through mapping service between IDs and 372 LIDs. Therefore, the mapping service in control plane infrastructure 373 can be considered as an NRS in this draft. 375 In MobilityFirst [MF], both consumer and publisher mobility can be 376 primarily handled by the global name resolution service (GNRS) which 377 resolves GUIDs to network addresses. Thus, the GNRS must be updated 378 for mobility support when a network attached object changes its point 379 of attachment, which differs from NDN/CCNx. 381 In NetInf [Dannewitz], mobility is handled by an NRS in a very 382 similar way to MobilityFirst. 384 Besides the consumer and producer mobility, ICN also has to face 385 challenges to support the other dynamic features such as multi- 386 homing, migration, and replication of named resources such as 387 content, devices, and services. Therefore, an NRS can help to 388 support these dynamic features. 390 3.3. Support scalable routing system 392 In ICN, the name of data objects is used for routing by either a name 393 resolution step or a routing table lookup. Thus, routing information 394 for each data object should be maintained in the routing base, such 395 as Routing Information Base (RIB) and Forwarding Information Base 396 (FIB). Since the number of data objects would be very large, the 397 size of information bases would be significantly larger as well 398 [RFC7927]. 400 The hierarchical namespace used in CCNx [CCNx] and NDN [NDN] 401 architectures reduces the size of these tables through name 402 aggregation and improves the scalability of the routing system. A 403 flat naming scheme, on the other hand, would aggravate the 404 scalability problem of the routing system. The non-aggregated name 405 prefixes injected to the Default Route Free Zone (DFZ) of ICN would 406 create more serious scalability problem when compared to the 407 scalability issues of the IP routing system. Thus, an NRS may play 408 an important role in the reduction of the routing scalability problem 409 regardless of the types of namespaces. 411 In [Afanasyev], in order to address the routing scalability problem 412 in NDN's DFZ, a well-known concept of Map-and-Encap is applied to 413 provide a simple and secure namespace mapping solution. In the 414 proposed map-and-encap design, data whose name prefixes do not exist 415 in the DFZ forwarding table can be retrieved by a distributed mapping 416 system called NDNS, which maintains and lookups the mapping 417 information from a name to its globally routed prefixes, where NDNS 418 is a kind of an NRS. 420 3.4. Support off-path caching 422 Caching in-network is considered to be a basic architectural 423 component of an ICN architecture. It may be used to provide a level 424 of Quality-of-Service (QoS) experience to users, to reduce the 425 overall network traffic, to prevent network congestion and Denial-of- 426 Service (DoS) attacks and to increase availability. Caching 427 approaches can be categorized into off-path caching and on-path 428 caching based on the location of caches in relation to the forwarding 429 path from the original server to the consumer. Off-path caching, 430 also referred as content replication or content storing, aims to 431 replicate content within a network in order to increase availability, 432 regardless of the relationship of the location to the forwarding 433 path. Thus, finding off-path cached objects is not trivial in name- 434 based routing of ICN. In order to support off-path caches, replicas 435 are usually advertised into a name-based routing system or into an 436 NRS. 438 In [Bayhan], an NRS is used to find off-path copies in the network, 439 which may not be accessible via name-based routing mechanisms. Such 440 capability can be helpful for an Autonomous System (AS) to avoid the 441 costly inter-AS traffic for external content more, to yield higher 442 bandwidth efficiency for intra-AS traffic, and to decrease the data 443 access latency for a pleasant user experience. 445 3.5. Support nameless object 447 In CCNx 1.0 [Mosko2], the concept of "Nameless Objects" that are a 448 Content Object without a Name is introduced to provide a means to 449 move Content between storage replicas without having to rename or re- 450 sign the content objects for the new name. Nameless Objects can be 451 addressed by the ContentObjectHash that is to restrict Content Object 452 matching by using SHA-256 hash. 454 An Interest message would still carry a Name and a ContentObjectHash, 455 where a Name is used for routing, while a ContentObjectHash is used 456 for matching. However, on the reverse path, if the Content Object's 457 name is missing, it is a "Nameless Object" and only matches against 458 the ContentObjectHash. Therefore, a consumer needs to resolve proper 459 name and hashes through an outside system, which can be considered as 460 an NRS. 462 3.6. Support manifest 464 For collections of data objects which are organized as large and file 465 like contents [FLIC], manifests are used as data structures to 466 transport this information. Thus, manifests may contain hash digests 467 of signed content objects or other manifests, so that large content 468 objects which represent large piece of application data can be 469 collected by using such manifest. 471 In order to request content objects, a consumer needs to know a 472 manifest root name to acquire the manifest. In case of FLIC, a 473 manifest name can be represented by a nameless root manifest, so that 474 outside system such as an NRS may be involved to give this 475 information to the consumer. 477 3.7. Support metadata 479 When resolving the name of a content object, NRS could return a rich 480 set of metadata in addition to returning a locator. The metadata 481 could include alternative object locations, supported object transfer 482 protocol(s), caching policy, security parameters, data format, hash 483 of object data, etc. The consumer could use this metadata for 484 selection of object transfer protocol, security mechanism, egress 485 interface, etc. An example of how metadata can be used in this way 486 is provided by the NEO ICN architecture [NEO]. 488 4. Design considerations for NRS in ICN 490 This section presents the design considerations for NRS in ICN, not 491 requirements. The key words "MUST", "MAY", and "SHOULD" in this 492 section are used consistently with [RFC2119]. 494 4.1. Resolution response time 496 The name resolution process should provide a response within a 497 reasonable amount of time. The response should be either a proper 498 mapping of the name to a copy of the content, or an error message 499 stating that no such object exists. If the name resolution does not 500 map to a location, the system may not issue any response, and the 501 client should set a timer when sending a request, so as to consider 502 the resolution incomplete when the timer expires. 504 The acceptable response delay could be of the order of a round trip 505 time between the client issuing the request and the NRS servers that 506 provides the response. While this RTT may vary greatly depending on 507 the proximity between the two end points, some upper bound need be 508 used. Especially, in some delay-sensitive scenarios such as 509 industrial Internet and telemedicine, the upper bound of the response 510 delay must be guaranteed. 512 The response time includes all the steps of the resolution, including 513 potentially a hop-by-hop resolution or a hierarchical forwarding of 514 the resolution request. 516 4.2. Response accuracy 518 An NRS must provide an accurate response, namely a proper binding of 519 the requested name (or prefix) with a location. The response can be 520 either a (prefix, location) pair, or the actual forwarding of a 521 request to a node holding the content, which is then transmitted in 522 return. 524 An NRS must provide an up-to-date response, namely an NRS should be 525 updated within a reasonable time when new copies of the content are 526 being stored in the network. While every transient cache addition/ 527 eviction should not trigger an NRS update, some origin servers may 528 move and require the NRS to be updated. 530 An NRS must provide mechanisms to update the mapping of the content 531 with its location. Namely, an NRS must provide a mechanism for a 532 content provider to add new content, revoke old/dated/obsolete 533 content, and modify existing content. Any content update should then 534 be propagated through the NRS system within reasonable delay. 536 Content that is highly mobile may require to specify some type of 537 anchor that is kept at the NRS, instead of the content location. 539 4.3. Resolution guarantee 541 An NRS must ensure that the name resolution is successful with high 542 probability if the name matching content exists in the network, 543 regardless of its popularity and number of cached copies existing in 544 the network. As per Section 4.1, some resolution may not occur in a 545 timely manner. However, the probability of such event should be 546 minimized. The NRS system may provide a probability (say, five 9s, 547 or five sigmas for instance) that a resolution will be satisfied. 549 4.4. Resolution fairness 551 An NRS could provide this service for all content in a fair manner, 552 independently of the specific content properties (content producer, 553 content popularity, availability of copies, content format, etc.). 554 Fairness may be defined as a per request delay to complete the NRS 555 steps that is not agnostic to the properties of the content itself. 556 Fairness may be defined as well as the number of requests answered 557 per unit of time. 559 However, it is notable that content (or their associated producer) 560 may request a different level of QoS from the network (see [QoSarch] 561 for instance), and this may include the NRS as well, in which case 562 considerations of fairness may be restricted to content within the 563 same class of service. 565 4.5. Scalability 567 The NRS system must scale up to support a very large user population 568 (including human users as well as machine-to-machine communications). 569 As an idea of the scale, it is expected that 50 billion devices will 570 be connected in 2025 (per ITU projections). The system must be able 571 to respond to a very large number of requests per unit of time. 573 Message forwarding and processing, routing table building-up and name 574 records propagation must be efficient and scalable. 576 The NRS system must scale up with the number of pieces of content 577 (content names) and should be able to support a content catalog that 578 is extremely large. Internet traffic is of the order of the 579 zettabytes per year (10^21 bytes). Since NRS is associated with 580 actual traffic, the number of pieces of content should scale with the 581 amount of traffic. Content size may vary from a few bytes to several 582 GB, so the NRS should be expected scale up to catalog of the size of 583 10^21 in the near future, and larger beyond. 585 The NRS system must be able to scale up, namely to add NRS servers to 586 the NRS system, in a way that is transparent to the users. Addition 587 of a new server should have limited negative impact on the other NRS 588 servers (or should have a negative impact on only a small subset of 589 the NRS servers). The impact of adding new servers may induce some 590 overhead at the other servers to rebuild a hierarchy or to exchange 591 messages to include the new server within the service. Further, data 592 may be shared among the new servers, for load balancing or tolerance 593 to failure. These steps should not disrupt the service provided by 594 the NRS and should in the long run improve the quality of the 595 service. 597 The NRS system may support access from a heterogeneity of connection 598 methods and devices. In particular, the NRS system may support 599 access from constrained devices and interactions with the NRS system 600 would not be too costly. An IoT node for instance should be able to 601 access the NRS system as well as a more powerful node. 603 The NRS system should scale up in its responsiveness to the increased 604 request rate that is expected from applications such as IoT or M2M, 605 where data is being frequently generated and/or frequently requested. 607 4.6. Manageability 609 The NRS system must be manageable since some parts of the system may 610 grow or shrink dynamically and an NRS system node may be added or 611 deleted frequently. 613 The NRS system may support an NRS management layer that allows for 614 adding or subtracting NRS nodes. In order to infer the circumstance, 615 the management layer can measure network status. 617 4.7. Deployed system 619 The NRS system must be deployable since deployability is important 620 for a real-world system. The NRS system must be deployable in 621 network edges and cores so that the consumers as well as ICN routers 622 can perform name resolution in a very low latency. 624 4.8. Fault tolerance 626 The NRS system must ensure resiliency in the event of NRS server 627 failures. The failure of a small subset of nodes should not impact 628 the NRS performance significantly. 630 After an NRS server fails, the NRS system must be able to recover 631 and/or restore the name records stored in the NRS server. 633 4.9. Security and privacy 635 On utilizing an NRS in ICN, there are some security considerations 636 for the NRS servers/nodes and name mapping records stored in the NRS 637 system. This subsection describes them. 639 4.9.1. Confidentiality 641 The name mapping records in the NRS system must be assigned with 642 proper access rights such that the information contained in the name 643 mapping records would not be revealed to unauthorized users. 645 The NRS system may support access control for certain name mapping 646 records. Access control can be implemented with a reference monitor 647 that uses client authentication, so only users with appropriate 648 credentials can access these records, and they are not shared with 649 unauthorized users. Access control can also be implemented by 650 encryption-based techniques using control of keys to control the 651 propagations of the mappings. 653 The NRS system may support obfuscation and/or encryption mechanisms 654 so that the content of a resolution request may not be accessible by 655 third parties outside of the NRS system. 657 The NRS system must keep confidentiality to prevent sensitive name 658 mapping records from being reached by unauthorized data requesters. 659 This is more required in IoT environments where a lot of sensitive 660 data is produced. 662 The NRS system must also keep confidentiality of meta-data as well as 663 NRS usage to protect the privacy of the users. For instance, a 664 specific user's NRS requests should not be shared outside the NRS 665 system (with the exception of legal intercept). 667 4.9.2. Authentication 669 o NRS server authentication: Authentication of the new NRS servers/ 670 nodes that want to be registered with the NRS system must be 671 required so that only authenticated entities can store and update 672 name mapping records. The NRS system should detect an attacker 673 attempting to act as a fake NRS server to cause service disruption 674 or manipulate name mapping records. 676 o Producer authentication: The NRS system must support 677 authentication of the content producers to ensure that 678 update/addition/removal of name mapping records requested by 679 content producers are actually valid and that content producers 680 are authorized to modify (or revoke) these records or add new 681 records. 683 o Mapping record authentication: The NRS should verify new mapping 684 records that are being registered so that it cannot be polluted 685 with falsified information or invalid records. 687 4.9.3. Integrity 689 The NRS system must be prevented from malicious users attempting to 690 hijack or corrupt the name mapping records. 692 4.9.4. Resiliency and availability 694 The NRS system should be resilient against denial of service attacks 695 and other common attacks to isolate the impact of the attacks and 696 prevent collateral damage to the entire system. Therefore, if a part 697 of the NRS system fails, the failure should only affect a local 698 domain. And fast recovery mechanisms need to be in place to bring 699 the service back to normal. 701 5. Conclusion 703 ICN routing may comprise three steps: name resolution, content 704 request routing, and content delivery. This document investigates 705 the name resolution step, which is the first and most important to be 706 achieved for ICN routing to be successful. A Name Resolution Service 707 (NRS) in ICN is defined as the service that provides such a function 708 of name resolution for translating an object name into some other 709 information such as a locator, another name, metadata, next hop info, 710 etc. that is used for forwarding the object request. 712 This document classifies and analyzes the NRS approaches according to 713 whether the name resolution step is separated from the content 714 request routing as an explicit process or not. This document also 715 explains the NRS functions used to support heterogeneous name types, 716 producer mobility, scalable routing system, off-path caching, 717 nameless object, manifest, and metadata. Finally, this document 718 presents design considerations for NRS in ICN, which include 719 resolution response time and accuracy, resolution guarantee, 720 resolution fairness, scalability, manageability, deployed system, and 721 fault tolerance. 723 6. IANA Considerations 725 There are no IANA considerations related to this document. 727 7. Security Considerations 729 A discussion of security guidelines was provided in section 4.9. 731 8. Acknowledgements 733 The authors would like to thank Dave Oran (ICNRG Co-chair), Ved 734 Kafle, and Vincent Roca for very useful reviews, comments and 735 improvement on the document. 737 9. References 739 9.1. Normative References 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, 743 DOI 10.17487/RFC2119, March 1997, 744 . 746 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 747 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 748 "Information-Centric Networking (ICN) Research 749 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 750 . 752 9.2. Informative References 754 [Ahlgren] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., 755 and B. Ohlman, "A Survey of Information-Centric 756 Networking", IEEE Communications Magarzine Vol.50, Issue 757 7, 2012. 759 [Xylomenos] 760 Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., 761 Tsilopoulos, C., Vasilako, X., Katsaros, K., and G. 762 Polyzos, "A Survey of Information-Centric Networking 763 Research,Communications Surveys and Tutorials", IEEE 764 Communications Surveys and Tutorials vol. 16, no. 2, 2014. 766 [Baccelli] 767 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 768 Wahlisch, "Information Centric Networking in the IoT: 769 Experiments with NDN in the Wild", ACM ICN 2014, 2014. 771 [Amadeo] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named 772 data networking for IoT: An architectural perspective", 773 European Conference on Networks and Communications 774 (EuCNC) , 2014. 776 [Quevedo] Quevedo, J., Corujo, D., and R. Aguiar, "A case for ICN 777 usage in IoT environments", IEEE GLOBECOM , 2014. 779 [Amadeo2] Amadeo, M. et al., "Information-centric networking for the 780 internet of things: challenges and opportunitiesve", IEEE 781 Network vol. 30, no. 2, July 2016. 783 [ID.Zhang2] 784 Zhang, Y., "Design Considerations for Applying ICN to 785 IoT", draft-zhang-icnrg-icniot-01 , June 2017. 787 [Koponen] Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim, 788 K., Shenker, S., and I. Stoica, "A Data-Oriented (and 789 Beyond) Network Architecture", ACM SIGCOMM 2007 pp. 790 181-192, 2007. 792 [PURSUIT] "FP7 PURSUIT project.", 793 http://www.fp7-pursuit.eu/PursuitWeb/ . 795 [SAIL] "FP7 SAIL project.", http://www.sail-project.eu/ . 797 [NDN] "NSF Named Data Networking project.", 798 http://www.named-data.net . 800 [CCNx] "Content Centric Networking project.", 801 https://wiki.fd.io/view/Cicn . 803 [MF] "NSF Mobility First project.", 804 http://mobilityfirst.winlab.rutgers.edu/ . 806 [Jung] Jung, H. et al., "IDNet: Beyond All-IP Network", ETRI 807 Jouranl vol. 37, no. 5, October 2015. 809 [SA2-5GLAN] 810 3gpp-5glan, "SP-181129, Work Item Description, 811 Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and 812 LAN Services", 3GPP , 813 http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP- 814 181120.zip. 816 [Bari] Bari, M., Chowdhury, S., Ahmed, R., Boutaba, R., and B. 817 Mathieu, "A Survey of Naming and Routing in Information- 818 Centric Networks", IEEE Communications Magazine Vol. 50, 819 No. 12, P.44-53, 2012. 821 [Westphal] 822 Westphal, C. and E. Demirors, "An IP-based Manifest 823 Architecture for ICN", ACM ICN , 2015. 825 [Mosko] Mosko, M., Scott, G., Solis, I., and C. Wood, "CCNx 826 Manifest Specification", draft-wood-icnrg- 827 ccnxmanifests-00 , July 2015. 829 [RFC6920] Farrell , S., Kutscher, D., Dannewitz, C., Ohlman, B., 830 Keranen, A., and P. Hallam-Baker, "Naming Things with 831 Hashes", RFC6920, DOI 10.17487/RFC6920, 832 https://rfc-editor.org/rfc/rfc6920.txt , Apr. 2013. 834 [Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data 835 Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES, 836 ALGORITHMS, AND APPLICATIONS(NOM) , 2016. 838 [Dannewitz] 839 Dannewitz, C. et al., "Network of Information (NetInf)-An 840 information centric networking architecture", Computer 841 Communications vol. 36, no. 7, April 2013. 843 [Ravindran] 844 Ravindran, R. et al., "Forwarding-Label support in CCN 845 Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July 846 2017. 848 [Afanasyev] 849 Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to 850 Scale NDN Forwarding", IEEE Global Internet Symposium , 851 April 2015. 853 [Mosko2] Mosko, M., "Nameless Objects", , July 2015. 855 [Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path 856 Caching in Information-Centric Networks", ACM ICN , 857 September 2016. 859 [FLIC] Tschudin, C. and C. Wood, "File-Like ICN Collection 860 (FLIC)", draft-irtf-icnrg-flic-01 , June 2018. 862 [NEO] Eriksson, A. and A. M. Malik, "A DNS-based information- 863 centric network architecture open to multiple protocols 864 for transfer of data objects", 21st Conference on 865 Innovation in Clouds, Internet and Networks and Workshops 866 (ICIN), pp. 1-8, 2018. 868 [NRSarch] Hong, J. et al., "Architectural Considerations of ICN 869 using Name Resolution Service", draft-irtf-icnrg-nrsarch- 870 considerations-05 , September 2020. 872 [QoSarch] Oran, D., "Considerations in the development of a QoS 873 Architecture for CCNx-like ICN protocols", draft-oran- 874 icnrg-qosarch-05 , August 2020. 876 Authors' Addresses 878 Jungha Hong 879 ETRI 880 218 Gajeong-ro, Yuseung-Gu 881 Daejeon 34129 882 Korea 884 Email: jhong@etri.re.kr 886 Tae-Wan You 887 ETRI 888 218 Gajeong-ro, Yuseung-Gu 889 Daejeon 34129 890 Korea 892 Email: twyou@etri.re.kr 894 Lijun Dong 895 Futurewei Technologies Inc. 896 10180 Telesis Court 897 San Diego, CA 92121 898 USA 900 Email: lijun.dong@futurewei.com 901 Cedric Westphal 902 Futurewei Technologies Inc. 903 2330 Central Expressway 904 Santa Clara, CA 95050 905 USA 907 Email: cedric.westphal@futurewei.com 909 Borje Ohlman 910 Ericsson Research 911 S-16480 Stockholm 912 Sweden 914 Email: Borje.Ohlman@ericsson.com