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