idnits 2.17.1 draft-irtf-icnrg-nrs-requirements-03.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 (November 04, 2019) is 1634 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-03 == Outdated reference: A later version (-06) exists of draft-oran-icnrg-qosarch-02 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 Y-G. Hong 5 Expires: May 7, 2020 ETRI 6 L. Dong 7 C. Westphal 8 Futurewei Technologies Inc. 9 B. Ohlman 10 Ericsson 11 November 04, 2019 13 Design Guidelines for Name Resolution Service in ICN 14 draft-irtf-icnrg-nrs-requirements-03 16 Abstract 18 This document discusses the functionalities and design guidelines for 19 Name Resolution Service (NRS) in ICN. The NRS in ICN is to translate 20 an object name into some other information such as a locator, another 21 name, etc. for forwarding the object request. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 7, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 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 . . . . . . . . . . . . 6 65 3.2. Support producer mobility . . . . . . . . . . . . . . . . 7 66 3.3. Support scalable routing system . . . . . . . . . . . . . 9 67 3.4. Support off-path caching . . . . . . . . . . . . . . . . 9 68 3.5. Support nameless object . . . . . . . . . . . . . . . . . 10 69 3.6. Support manifest . . . . . . . . . . . . . . . . . . . . 10 70 3.7. Support metadata . . . . . . . . . . . . . . . . . . . . 10 71 4. Design guidelines for NRS in ICN . . . . . . . . . . . . . . 11 72 4.1. Resolution response time . . . . . . . . . . . . . . . . 11 73 4.2. Response accuracy . . . . . . . . . . . . . . . . . . . . 11 74 4.3. Resolution guarantee . . . . . . . . . . . . . . . . . . 12 75 4.4. Resolution fairness . . . . . . . . . . . . . . . . . . . 12 76 4.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.6. Manageability . . . . . . . . . . . . . . . . . . . . . . 13 78 4.7. Deployed system . . . . . . . . . . . . . . . . . . . . . 13 79 4.8. Fault tolerance . . . . . . . . . . . . . . . . . . . . . 13 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 6.1. Accessibility . . . . . . . . . . . . . . . . . . . . . . 14 83 6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 14 84 6.3. Data confidentiality . . . . . . . . . . . . . . . . . . 14 85 6.4. Privacy protection . . . . . . . . . . . . . . . . . . . 15 86 6.5. Robustness/resiliency . . . . . . . . . . . . . . . . . . 15 87 6.6. Network privacy . . . . . . . . . . . . . . . . . . . . . 15 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 91 8.2. Informative References . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 The current Internet is a host-centric networking, where hosts are 97 uniquely identified with IP addresses and communication is possible 98 between any pair of hosts. Thus, information in the current Internet 99 is identified by the name of host where the information is stored. 100 In contrast to the host-centric networking, the primary communication 101 objects in Information-centric networking (ICN) are the named data 102 objects (NDOs) and they are uniquely identified by the location- 103 independent names. Thus, ICN aiming to the efficient dissemination 104 and retrieval of the NDOs in a global scale has been identified and 105 acknowledged as a promising technology for the future Internet 106 architecture to overcome the limitations of the current Internet such 107 as scalability and mobility.[Ahlgren] [Xylomenos]. ICN also has been 108 emerged as a candidate architecture for IoT environment since IoT 109 focuses on data and information rather than end-to-end communications 110 [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2]. 112 Since naming data independently from the current location where it is 113 stored is a primary concept of ICN, how to find the NDO using the 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 o Name resolution : matches/translates a content name to locators of 119 content producers or sources that can provide the content. 121 o Content request routing : routes the content request towards the 122 content's location either based on its name or locator. 124 o Content delivery : transfers the content to the requester. 126 Among these three steps of ICN routing, this document focuses only on 127 the name resolution step which translates a content name to the 128 content locators. In addition, this document covers various possible 129 types of name resolution in ICN such as one name to another name, 130 name to manifest, name to locator, name to metadata, etc. 132 This document presents the overview of the Name Resolution Service 133 (NRS) approaches in ICN and also discusses the functionalities and 134 the guidelines in designing the NRS for ICN. This document focuses 135 on NRS itself as a service or a system in ICN, while [NRSarch] 136 document focuses on the ICN architectural considerations for NRS. 138 2. Name Resolution Service in ICN 140 The Name Resolution Service (NRS) in ICN is defined as the service 141 that provides the name resolution function for translating an object 142 name into some other information such as a locator, another name, 143 metadata, etc. that is used for forwarding the object request. In 144 other words, the NRS is a service that can be provided by ICN 145 infrastructure to help a consumer to reach a specific piece of 146 information objects. The consumer provides the NRS with a persistent 147 name and the NRS returns a name or locator that can reach a current 148 instance of the requested object. 150 The name resolution is a necessary process in ICN routing although 151 the name resolution either can be separated from the content request 152 routing as an explicit process or can be integrated with the content 153 request routing as an implicit process. The former is referred as 154 explicit name resolution approach, the latter is referred as name- 155 based routing approach in this document. 157 2.1. Explicit name resolution approach 159 The NRS could take the explicit name resolution approach to return 160 the client with the locators of the content, which will be used by 161 the underlying network as the identifier to route the client's 162 request to one of the producers. There are several ICN projects that 163 use the explicit name resolution approach such as DONA [Koponen], 164 PURSUIT [PURSUIT], NetInf [SAIL], MobilityFirst [MF], IDNet [Jung], 165 etc. In addition, the explicit name resolution approach has been 166 allowed for 5G control planes [SA2-5GLAN]. 168 2.2. Name-based routing approach 170 The NRS could take the name-based routing approach, which integrates 171 the name resolution with the content request message routing as in 172 NDN [NDN]/CCNx [CCNx]. 174 In the case that the content request also specifies the reverse path, 175 as in NDN/CCNx, the name resolution mechanism also derives the 176 routing path for the data. This adds a requirement on the name 177 resolution service to propagate request in a way that is consistent 178 with the subsequent data forwarding. Namely, the request must select 179 a path for the data based upon the finding the copy of the content, 180 but also properly delivering the data. 182 2.3. Hybrid approach 184 The NRS could also take hybrid approach which can perform the name- 185 based routing approach from the beginning. When it fails at certain 186 router, the router can go back to the explicit name resolution 187 approach. The alternative hybrid NRS approach also works, which can 188 perform explicit name resolution approach from the beginning to find 189 locators of routers. And then it can carry out the name-based 190 routing approach of the client's request. 192 A hybrid approach would combine name resolution as a subset of 193 routers on the path with some tunneling in between (say, across an 194 administrative domain) so that only a few of the nodes in the ICN 195 network perform name resolution in the name-based routing approach. 197 2.4. Comparisons of name resolution approaches 199 The following compares the explicit name resolution and the name- 200 based routing approaches from different aspects: 202 o Update message overhead : The update message overhead is due to 203 the change of content reachability, which may include content 204 caching or expiration, content producer mobility etc. The name- 205 based routing approach may require flooding parts of the network 206 for update propagation. In the worst case, the name-based routing 207 approach may flood the whole network (but mitigating techniques 208 may be used to scope the flooding). However, the explicit name 209 resolution approach only requires updating propagation in part of 210 the name resolution overlay. 212 o Resolution capability : The explicit name resolution approach, if 213 designed and deployed with sufficient robustness, can offer at 214 least weak guarantees that resolution will succeed for any content 215 name in the network if it is registered to the name resolution 216 overlay. In the name-based routing approach, content resolution 217 depends on the flooding scope of the content names (i.e. content 218 publishing message and the resulting name based routing tables). 219 For example, when a content is cached, the router may only notify 220 this information to its direct neighbors. Thus only those 221 neighboring routers can build a named based entry for this cached 222 content. But if the neighboring routers continue to propagate 223 this information, the other nodes are able to direct to this 224 cached copy as well. 226 o Node failure impact : Nodes involved in the explicit name 227 resolution approach are the name resolution overlay servers (e.g. 228 Resolution Handlers in DONA), while the nodes involved in the 229 name-based routing approach are routers which route messages based 230 on the name-based routing tables (e.g. NDN routers). Node 231 failures in the explicit name resolution approach may cause some 232 content discovery to fail even though the content is available. 233 This problem does not exist in the name-based routing approach 234 because other alternative paths can be discovered to bypass the 235 failed ICN routers, given the assumption that the network is still 236 connected. 238 o Maintained databases : The storage usage for the explicit name 239 resolution approach is different from that of the name-based 240 routing approach. The explicit name resolution approach typically 241 needs to maintain two databases: name to locator mapping in the 242 name resolution overlay and routing tables in the routers on the 243 data forwarding plane. The name-based routing approach needs to 244 maintain only the name-based routing tables. 246 Additionally, some other intermediary step may be included in the 247 name resolution, namely the mapping of one name to other names, in 248 order to facilitate the retrieval of named content, by way of a 249 manifest [Westphal] [Mosko]. The manifest is resolved using one of 250 the two above approaches, and it may include further mapping of names 251 to content and location. The steps for name resolution then become: 252 first translate the manifest name into a location of a copy of the 253 manifest; the manifest includes further names of the content 254 components, and potentially locations for the content. The content 255 is then retrieved by using these names and/or location, potentially 256 resulting in additional name resolutions. 258 Thus, no matter which approach is taken by the NRS in ICN, the name 259 resolution is the essential function that shall be provided by the 260 ICN infrastructure. 262 3. Functionalities of NRS in ICN 264 This section presents the functionalities of NRS in ICN. 266 3.1. Support heterogeneous name types 268 In ICN, a name is used to identify data object and is bound to it 269 [RFC7927]. ICN requires uniqueness and persistency of the name of 270 data object to ensure the reachability of the object within a certain 271 scope. There are heterogeneous approaches to designing ICN naming 272 schemes [Bari]. Ideally, a name can include any form of identifier, 273 which can be flat, hierarchical, and human readable or non-readable. 275 Although there are diverse types of naming schemes proposed in 276 literature, they all need to provide basic functions for identifying 277 data object, supporting named data lookup and routing. The NRS may 278 combine the good aspects of different schemes. Basically, the NRS 279 should be able to support a generic naming schema so that it can 280 resolve any type of content name, irrespective of whether it is flat, 281 hierarchical, attributed based or anything else. 283 In PURSUIT [PURSUIT], names are flat and the rendezvous functions are 284 defined for NRS, which is implemented by a set of Rendezvous Nodes 285 (RNs), the Rendezvous Network (RENE). Thus a name consisted of a 286 sequence of scope IDs and a single rendezvous ID is routed by RNs in 287 RENE. Thus, PURSUIT decouples name resolution and data routing, 288 where NRS is performed by the RENE. 290 In MobilityFirst [MF], a name called a global unique Identifier 291 (GUID) derived from a human-readable name via a global naming service 292 is flat typed 160-bits strings with self-certifying properties. 293 Thus, MobilityFirst defines a global name resolution service (GNRS) 294 which resolves GUIDs to network addresses and decouples name 295 resolution and data routing as similar to PURSUIT. 297 In NetInf [Dannewitz], information objects are named using ni-naming 298 [RFC6920], which consist of an authority part and digest part 299 (content hash). The ni names can be flat as the authority part is 300 optional. Thus, the NetInf architecture also includes a Name 301 Resolution System (NRS) which can be used to resolve ni-names to 302 addresses in an underlying routable network layer. 304 In NDN [NDN] and CCNx [CCNx], names are hierarchical and may be 305 similar to URLs. Each name component can be anything, including a 306 dotted human-readable string or a hash value. NDN/CCNx adopts the 307 name based routing approach. The NDN router forwards the request by 308 doing the longest-match lookup in the Forwarding Information Base 309 (FIB) based on the content name and the request is stored in the 310 Pending Interest Table (PIT). 312 3.2. Support producer mobility 314 ICN natively supports mobility management. Especially, consumer or 315 client mobility is handled by requesting the content again in case 316 the mobility or handover occurred before receiving the corresponding 317 content from the network. Since ICN can ensure that content 318 reception continues without any disruption in ICN application, 319 seamless mobility in consumer point of view can be easily supported. 321 However, producer mobility does not emerge naturally from the ICN 322 forwarding model as does consumer mobility. If a producer moves into 323 a different network location or a different name domain, which is 324 assigned by another authoritative publisher, it would be difficult 325 for the mobility management update RIB and FIB entries in ICN routers 326 with the new forwarding path in a very short time. Therefore, 327 various ICN architectures in literatures have proposed to adopt NRS 328 to achieve the producer or publisher mobility, where NRS can be 329 implemented in different ways such as at rendezvous points and 330 overlay mapping systems. 332 In NDN [Zhang2], for producer mobility support, rendezvous mechanisms 333 have been proposed to build interests rendezvous (RV) with data 334 generated by a mobile producer (MP). There can be classified two 335 approaches such as chase mobile producer and rendezvous data. 336 Regarding MP chasing, rendezvous acts as a mapping service that 337 provides the mapping from the name of the data produced by the MP to 338 the MP's current point of attachment (PoA) name. Alternatively, the 339 RV serves as a home agent like as IP mobility support, so the RV 340 enables consumer's interest message to tunnel towards the MP at the 341 PoA. Regarding rendezvous data, moving the data produced by the MP 342 have been hosting at data depot instead of forwarding interest 343 messages. Thus a consumer's interest message can be forwarded to 344 stationary place as called data rendezvous, so it would either return 345 the data or fetch it using another mapping solution. Therefore, RV 346 or other mapping functions are in the role of NRS in NDN. 348 In [Ravindran], forwarding-label (FL) object is referred to enable 349 identifier (ID) and locator (LID) namespaces to be split in ICN. 350 Generally, IDs are managed by applications, while locators are 351 managed by a network administrator, so that IDs are mapping to 352 heterogeneous name schemes and LIDs are mapping to network domains or 353 specific network elements. Thus the proposed FL object acts as a 354 locator (LID) and provides the flexibility to forward Interest 355 messages through mapping service between IDs and LIDs. Therefore, 356 the mapping service in control plane infrastructure can be considered 357 as NRS in this draft. 359 In MobilityFirst [MF], both consumer and publisher mobility can be 360 primarily handled by the global name resolution service (GNRS) which 361 resolves GUIDs to network addresses. Thus, the GNRS must be updated 362 for mobility support when a network attached object changes its point 363 of attachment, which differs from NDN/CCNx. 365 In NetInf [Dannewitz], mobility is handled by the NRS in a very 366 similar way as done in MobilityFirst. 368 Besides the consumer and producer mobility, ICN also has to face 369 challenges to support the other dynamic features such as multi- 370 homing, migration, and replication of named resources such as 371 content, devices, and services. Therefore, NRS can help to support 372 these dynamic features. 374 3.3. Support scalable routing system 376 In ICN, name of data objects is used for routing by either name 377 resolution step or routing table lookup. Thus, routing information 378 for each data object should be maintained in routing base, such as 379 Routing Information Base (RIB) and Forwarding Information Base (FIB). 380 Since the number of data objects would be very large, the size of 381 information bases would be significantly large as well [RFC7927]. 383 The hierarchical namespace used in CCNx [CCNx] and NDN [NDN] 384 architectures reduces the size of these tables through name 385 aggregation and improves scalability of routing system. In a flat 386 naming scheme, on the other hand, it would aggravate the scalability 387 problem in routing system. The non-aggregated name prefixes injected 388 to the Default Route Free Zone (DFZ) of ICN would create more serious 389 scalability problem similar to the scalability issue of IP routing 390 system. Thus, NRS may play an important role in the reduction of the 391 routing scalability problem regardless of the types of namespaces. 393 In [Afanasyev], in order to address the routing scalability problem 394 in NDN's DFZ, a well-known concept of Map-and-Encap is applied to 395 provide a simple and secure namespace mapping solution. In the 396 proposed map-and-encap design, data whose name prefixes do not exist 397 in the DFZ forwarding table can be retrieved by a distributed mapping 398 system called NDNS, which maintains and lookups the mapping 399 information from a name to its globally routed prefixes, where NDNS 400 is a kind of NRS. 402 3.4. Support off-path caching 404 Caching in-network is considered to be a basic architectural 405 component of an ICN architecture. It may be used to provide a 406 Quality-of-Service (QoS) experience to users, reduce the overall 407 network traffic, prevent network congestion and Denial-of-Service 408 (DoS) attacks and increase availability. Caching approaches can be 409 categorized into off-path caching and on-path caching based on the 410 location of caches in relation to the forwarding path from a original 411 server to a consumer. Off-path caching, also referred as content 412 replication or content storing, aims to replicate content within a 413 network in order to increase availability, regardless of the 414 relationship of the location to the forwarding path. Thus, finding 415 off-path cached objects is not trivial in name based routing of ICN. 416 In order to support off-path caches, replicas are usually advertised 417 into a name-based routing system or into NRS. 419 In [Bayhan], a NRS is used to find off-path copies in the network, 420 which may not be accessible via content discovery mechanisms. Such 421 capability can be helpful for an Autonomous System (AS) to avoid the 422 costly inter-AS traffic for external content more, to yield higher 423 bandwidth efficiency for intra-AS traffic, and to decrease the data 424 access latency for a pleasant user experience. 426 3.5. Support nameless object 428 In CCNx 1.0 [Mosko2], the concept of "Nameless Objects" that are a 429 Content Object without a Name is introduced to provide a means to 430 move Content between storage replicas without having to rename or re- 431 sign the content objects for the new name. Nameless Objects can be 432 addressed by the ContentObjectHash that is to restrict Content Object 433 matching by using SHA-256 hash. 435 An Interest message would still carry a Name and a ContentObjectHash, 436 where a Name is used for routing, while a ContentObjectHash is used 437 for matching. However, on the reverse path, if the Content Object's 438 name is missing, it is a "Nameless Object" and only matches against 439 the ContentObjectHash. Therefore, a consumer needs to resolve proper 440 name and hashes through an outside system, which can be considered as 441 NRS. 443 3.6. Support manifest 445 In collection of data objects which were organized as large and file 446 like contents [FLIC], the manifests are used as data structures to 447 transport this information. Thus, the manifests may contain hash 448 digests of signed content objects or other manifests, so that large 449 content objects which represent large piece of application data can 450 be collected by using the manifest. 452 In order to request content objects, a consumer needs to know a 453 manifest root name to acquire the manifest. In case of FLIC, a 454 manifest name can be represented by a nameless root manifest, so that 455 outside system such as NRS may be involved to give this information 456 to the consumer. 458 3.7. Support metadata 460 When resolving the name of a content object the NRS in addition to 461 returning a locator could return a rich set of metadata. The 462 metadata could include alternative object locations, supported object 463 transfer protocol(s), caching policy, security parameters, data 464 format, hash of object data, etc. The consumer could use this 465 metadata for selection of object transfer protocol, security 466 mechanism, egress interface, etc. An example of how metadata can be 467 used in this way is provided by the NEO ICN architecture [NEO]. 469 4. Design guidelines for NRS in ICN 471 This section presents the guidelines for designing NRS in ICN. 473 4.1. Resolution response time 475 The name resolution process should provide a response within a 476 reasonable amount of time. The response should be either a proper 477 mapping of the name to a copy of the content, or an error message 478 stating that no such object exists. If the name resolution does not 479 map to a location, the system may not issue any response, and the 480 client should set a timer when sending a request, so as to consider 481 the resolution incomplete when the timer expires. 483 The acceptable response delay should be of the order of a round trip 484 time between the client issuing the request and the NRS servers that 485 provides the response. While this RTT may be vary greatly depending 486 on the proximity between the two end points, some upper bound should 487 be used. Especially, in some delay-sensitive scenarios such as 488 industrial Internet and telemedicine, the upper bound of the response 489 delay must be guaranteed. 491 The response time should be within the same order of magnitude for 492 most pairs of a client issuing a request, and the NRS server 493 responding to this request. 495 The response time should include all the steps of the resolution, 496 including potentially a hop-by-hop resolution or a hierarchical 497 forwarding of the resolution request. 499 4.2. Response accuracy 501 The NRS must provide an accurate response, namely a proper binding of 502 the requested name (or prefix) with a location. The response can be 503 either a (prefix, location) pair, or the actual forwarding of a 504 request to a node holding the content, which is then transmitted in 505 return. 507 The NRS must provide an up-to-date response, namely the NRS should be 508 updated within a reasonable time when new copies of the content are 509 being stored in the network. While every transient cache addition/ 510 eviction should not trigger an NRS update, some origin servers may 511 move and require the NRS to be updated. 513 The NRS must provide mechanisms to update the mapping of the content 514 with its location. Namely, the NRS must provide a mechanism for a 515 content owner to add new content, revoke old/dated/obsolete content, 516 and modify existing content. Any content update should then be 517 propagated through the NRS system within reasonable delay. 519 Content that is highly mobile may require to specify some type of 520 anchor that is kept at the NRS, instead of the content location. 522 4.3. Resolution guarantee 524 The NRS must ensure that the name resolution would be successful if 525 the name matching content exists in the network, regardless of its 526 popularity and number of cached copies existing in the network. 528 4.4. Resolution fairness 530 The NRS should provide this service for all content in a fair manner, 531 independently of the specific content properties (content producer, 532 content popularity, availability of copies, content format, etc.). 533 Fairness may be defined as a per request delay to complete the NRS 534 steps that is not agnostic to the properties of the content itself. 535 Fairness may be defined as well as the number of requests answered 536 per unit of time. 538 However, it should be noted that content (or their associated 539 producer) may request a different level of QoS from the network (see 540 [QoSarch] for instance), and this may include the NRS as well, in 541 which case considerations of fairness may be restricted to content 542 within the same class of service. 544 4.5. Scalability 546 The NRS system must scale up to support a very large user population 547 (including human users as well as machine-to-machine communications). 548 As an idea of the scale, it is expected that 50 billion devices will 549 be connected in 2025 (per ITU projections). The system must be able 550 to respond to a very large number of requests per unit of time. 551 Message forwarding and processing, routing table building-up and name 552 records propagation must be efficient and scalable. 554 The NRS system must scale up with the number of pieces of content 555 (content names) and should be able to support a content catalog that 556 is extremely large. Internet traffic is of the order of the 557 zettabytes per year (10^21 bytes). Since NRS is associated with 558 actual traffic, the number of pieces of content should scale with the 559 amount of traffic. Content size may vary from a few bytes to several 560 GB, so the NRS should be expected scale up to catalog of the size of 561 10^21 in the near future, and larger beyond. 563 The NRS system must be able to scale up, namely to add NRS servers to 564 the NRS system, in a way that is transparent to the users. Addition 565 of a new server should have limited negative impact on the other NRS 566 servers (or should have a negative impact on only a small subset of 567 the NRS servers). The impact of adding new servers may induce some 568 overhead at the other servers to rebuild a hierarchy or to exchange 569 messages to include the new server within the service. Further, data 570 may be shared among the new servers, for load balancing or tolerance 571 to failure. These steps should not disrupt the service provided by 572 the NRS and should in the long run improve the quality of the 573 service. 575 The NRS system should support access from a heterogeneity of 576 connection methods and devices. In particular, the NRS system should 577 support access from constrained devices and interactions with the NRS 578 system should not be too costly. An IoT node for instance should be 579 able to access the NRS system as well as a more powerful node. 581 The NRS system should scale up in its responsiveness to the increased 582 request rate that is expected from applications such as IoT or M2M, 583 where data is being frequently generated and/or frequently requested. 585 4.6. Manageability 587 The NRS system must be manageable since some parts of the system may 588 grow or shrink dynamically and an NRS system node may be added or 589 deleted frequently. 591 The NRS may support an NRS management layer that allows for adding or 592 subtracting NRS nodes. In order to infer the circumstance, the 593 management layer can measure network status. 595 4.7. Deployed system 597 The NRS system must be deployable since deployability is important 598 for a real world system. The NRS system must be deployable in 599 network edges and cores so that the consumers as well as ICN routers 600 can perform name resolution in a very low latency. 602 4.8. Fault tolerance 604 The NRS system must ensure resiliency in the event of NRS server 605 failures. The failure of a small subset of nodes should not impact 606 the NRS performance significantly. 608 After a NRS server fails, the NRS system must be able to recover and/ 609 or restore the name records stored in the NRS server. 611 5. IANA Considerations 613 There are no IANA considerations related to this document. 615 6. Security Considerations 617 Accessibility, authentication, confidentiality and privacy protection 618 are the concerns on security aspect of both the NRS server nodes and 619 mapping records stored in the NRS system. 621 6.1. Accessibility 623 The name records must have assigned and updated with proper access 624 rights such that the information contained in the name mapping record 625 would not be revealed to unauthorized users or producers. 626 Additionally, the NRS system must be prevented from malicious users 627 attempting to corrupt the name mapping records. 629 The NRS may support access control for certain name records, so that 630 only users and producers within the proper lists can access these 631 records, and these records would not be shared to unauthorized users 632 and producers. 634 The NRS should support authentication of the content producers to 635 determine that any location update/addition/removal that a content 636 producer is requesting is indeed valid and that the content producer 637 is authorized to modify this record. 639 6.2. Authentication 641 The NRS must require authentication of new NRS nodes that register 642 themselves in the NRS system to ensure they are who they claim to be. 643 For example, it should detect an attacker attempting to act as a fake 644 NRS server to disrupt the NRS service, or to intercept some users' 645 data. 647 6.3. Data confidentiality 649 NRS must keep the data confidentiality to prevent a lot of sensitive 650 data from reaching unauthorized data requestor such as in IoT 651 environment. 653 NRS must keep meta-data confidential as well as usage to protect the 654 privacy of the users. For instance, a specific user's NRS requests 655 should not be shared outside the NRS system (with the exception of 656 legal intercept). 658 6.4. Privacy protection 660 When a private name mapping record is registered in the system, the 661 NRS system must support the privacy to avoid the information leaking. 662 Otherwise, unauthorized entity may disclose the privacy. 664 6.5. Robustness/resiliency 666 The NRS system should be resilient to denial of service attacks and/ 667 or other common attacks on the integrity of its system. The NRS 668 system should be resilient if a few attacked nodes are unable to 669 participate in the system. 671 6.6. Network privacy 673 The NRS node in a given subdomain should not leak information about 674 this domain (say, topology, number of nodes, number of clients, 675 number of requests) to nodes outside of this domain, except for 676 sharing the content that it is allowed to advertise, or for the 677 management protocols that it is supporting. 679 7. Acknowledgements 681 The authors would like to thank Ved Kafle for his valuable comments 682 and suggestions on this document. 684 8. References 686 8.1. Normative References 688 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 689 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 690 "Information-Centric Networking (ICN) Research 691 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 692 . 694 8.2. Informative References 696 [Ahlgren] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., 697 and B. Ohlman, "A Survey of Information-Centric 698 Networking", IEEE Communications Magarzine Vol.50, Issue 699 7, 2012. 701 [Xylomenos] 702 Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., 703 Tsilopoulos, C., Vasilako, X., Katsaros, K., and G. 704 Polyzos, "A Survey of Information-Centric Networking 705 Research,Communications Surveys and Tutorials", IEEE 706 Communications Surveys and Tutorials vol. 16, no. 2, 2014. 708 [Baccelli] 709 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 710 Wahlisch, "Information Centric Networking in the IoT: 711 Experiments with NDN in the Wild", ACM ICN 2014, 2014. 713 [Amadeo] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named 714 data networking for IoT: An architectural perspective", 715 European Conference on Networks and Communications 716 (EuCNC) , 2014. 718 [Quevedo] Quevedo, J., Corujo, D., and R. Aguiar, "A case for ICN 719 usage in IoT environments", IEEE GLOBECOM , 2014. 721 [Amadeo2] Amadeo, M. et al., "Information-centric networking for the 722 internet of things: challenges and opportunitiesve", IEEE 723 Network vol. 30, no. 2, July 2016. 725 [ID.Zhang2] 726 Zhang, Y., "Design Considerations for Applying ICN to 727 IoT", draft-zhang-icnrg-icniot-01 , June 2017. 729 [Koponen] Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim, 730 K., Shenker, S., and I. Stoica, "A Data-Oriented (and 731 Beyond) Network Architecture", ACM SIGCOMM 2007 pp. 732 181-192, 2007. 734 [PURSUIT] "FP7 PURSUIT project.", 735 http://www.fp7-pursuit.eu/PursuitWeb/ . 737 [SAIL] "FP7 SAIL project.", http://www.sail-project.eu/ . 739 [NDN] "NSF Named Data Networking project.", 740 http://www.named-data.net . 742 [CCNx] "Content Centric Networking project.", 743 https://wiki.fd.io/view/Cicn . 745 [MF] "NSF Mobility First project.", 746 http://mobilityfirst.winlab.rutgers.edu/ . 748 [Jung] Jung, H. et al., "IDNet: Beyond All-IP Network", ETRI 749 Jouranl vol. 37, no. 5, October 2015. 751 [SA2-5GLAN] 752 3gpp-5glan, "SP-181129, Work Item Description, 753 Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and 754 LAN Services", 3GPP , 755 http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP- 756 181120.zip. 758 [Bari] Bari, M., Chowdhury, S., Ahmed, R., Boutaba, R., and B. 759 Mathieu, "A Survey of Naming and Routing in Information- 760 Centric Networks", IEEE Communications Magazine Vol. 50, 761 No. 12, P.44-53, 2012. 763 [Westphal] 764 Westphal, C. and E. Demirors, "An IP-based Manifest 765 Architecture for ICN", ACM ICN , 2015. 767 [Mosko] Mosko, M., Scott, G., Solis, I., and C. Wood, "CCNx 768 Manifest Specification", draft-wood-icnrg- 769 ccnxmanifests-00 , July 2015. 771 [RFC6920] Farrell , S., Kutscher, D., Dannewitz, C., Ohlman, B., 772 Keranen, A., and P. Hallam-Baker, "Naming Things with 773 Hashes", RFC6920, DOI 10.17487/RFC6920, 774 https://rfc-editor.org/rfc/rfc6920.txt , Apr. 2013. 776 [Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data 777 Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES, 778 ALGORITHMS, AND APPLICATIONS(NOM) , 2016. 780 [Dannewitz] 781 Dannewitz, C. et al., "Network of Information (NetInf)-An 782 information centric networking architecture", Computer 783 Communications vol. 36, no. 7, April 2013. 785 [Ravindran] 786 Ravindran, R. et al., "Forwarding-Label support in CCN 787 Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July 788 2017. 790 [Afanasyev] 791 Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to 792 Scale NDN Forwarding", IEEE Global Internet Symposium , 793 April 2015. 795 [Mosko2] Mosko, M., "Nameless Objects", , July 2015. 797 [Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path 798 Caching in Information-Centric Networks", ACM ICN , 799 September 2016. 801 [FLIC] Tschudin, C. and C. Wood, "File-Like ICN Collection 802 (FLIC)", draft-irtf-icnrg-flic-01, , June 2018. 804 [NEO] Eriksson, A. and A. M. Malik, "A DNS-based information- 805 centric network architecture open to multiple protocols 806 for transfer of data objects", 21st Conference on 807 Innovation in Clouds, Internet and Networks and Workshops 808 (ICIN), pp. 1-8, 2018. 810 [NRSarch] Hong, J. et al., "Architectural Considerations of ICN 811 using Name Resolution Service", draft-irtf-icnrg-nrsarch- 812 considerations-03 , November 2019. 814 [QoSarch] Oran, D., "Considerations in the development of a QoS 815 Architecture for CCNx-like ICN protocols", draft-oran- 816 icnrg-qosarch-02 , October 2019. 818 Authors' Addresses 820 Jungha Hong 821 ETRI 822 218 Gajeong-ro, Yuseung-Gu 823 Daejeon 34129 824 Korea 826 Email: jhong@etri.re.kr 828 Tae-Wan You 829 ETRI 830 218 Gajeong-ro, Yuseung-Gu 831 Daejeon 34129 832 Korea 834 Email: twyou@etri.re.kr 836 Yong-Geun Hong 837 ETRI 838 218 Gajeong-ro, Yuseung-Gu 839 Daejeon 34129 840 Korea 842 Email: yghong@etri.re.kr 843 Lijun Dong 844 Futurewei Technologies Inc. 845 10180 Telesis Court 846 San Diego, CA 92121 847 USA 849 Email: lijun.dong@futurewei.com 851 Cedric Westphal 852 Futurewei Technologies Inc. 853 2330 Central Expressway 854 Santa Clara, CA 95050 855 USA 857 Email: cedric.westphal@futurewei.com 859 Borje Ohlman 860 Ericsson Research 861 S-16480 Stockholm 862 Sweden 864 Email: Borje.Ohlman@ericsson.com