idnits 2.17.1 draft-irtf-icnrg-nrs-requirements-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 08, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Jacobson' is defined on line 739, but no explicit reference was found in the text == Unused Reference: 'Baid' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'Rajahalme' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'Katsaros' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'ID.Wang' is defined on line 765, but no explicit reference was found in the text == Unused Reference: 'ID.Zhang' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'Sevilla' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'RFC1498' is defined on line 784, but no explicit reference was found in the text == Unused Reference: 'RFC7252' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'ID.Shelby' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'CoRE' is defined on line 800, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 812, but no explicit reference was found in the text == Unused Reference: 'RFC6833' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'Zhang' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'Seskar' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'Dannewitz2' is defined on line 843, but no explicit reference was found in the text == Unused Reference: 'Vu' is defined on line 849, but no explicit reference was found in the text == Unused Reference: 'Hong' is defined on line 854, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-10 -- No information found for draft-wood-icnrg-ccnxmanifests - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 6833 (Obsoleted by RFC 9301) == 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 Summary: 0 errors (**), 0 flaws (~~), 23 warnings (==), 4 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: January 9, 2020 ETRI 6 L. Dong 7 C. Westphal 8 Huawei 9 B. Ohlman 10 Ericsson 11 July 08, 2019 13 Design Guidelines for Name Resolution Service in ICN 14 draft-irtf-icnrg-nrs-requirements-02 16 Abstract 18 This document discusses the motivation and design guidelines for Name 19 Resolution Service (NRS) in ICN. The NRS in ICN is to translate an 20 object name into some other information such as a locator and another 21 name which is used 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 January 9, 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. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 59 3. Name Resolution Service in ICN . . . . . . . . . . . . . . . 4 60 3.1. Explicit name resolution approach . . . . . . . . . . . . 4 61 3.2. Name-based routing approach . . . . . . . . . . . . . . . 4 62 3.3. Hybrid approach . . . . . . . . . . . . . . . . . . . . . 4 63 3.4. Comparisons of name resolution approaches . . . . . . . . 5 64 4. Functionalities of NRS in ICN . . . . . . . . . . . . . . . . 6 65 4.1. Support heterogeneous name types . . . . . . . . . . . . 6 66 4.2. Support producer mobility . . . . . . . . . . . . . . . . 7 67 4.3. Support scalable routing system . . . . . . . . . . . . . 9 68 4.4. Support off-path caching . . . . . . . . . . . . . . . . 9 69 4.5. Support nameless object . . . . . . . . . . . . . . . . . 10 70 4.6. Support manifest . . . . . . . . . . . . . . . . . . . . 10 71 4.7. Support metadata . . . . . . . . . . . . . . . . . . . . 10 72 5. Design guidelines for NRS in ICN . . . . . . . . . . . . . . 11 73 5.1. Resolution response time . . . . . . . . . . . . . . . . 11 74 5.2. Response accuracy . . . . . . . . . . . . . . . . . . . . 11 75 5.3. Resolution guarantee . . . . . . . . . . . . . . . . . . 12 76 5.4. Resolution fairness . . . . . . . . . . . . . . . . . . . 12 77 5.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12 78 5.6. Manageability . . . . . . . . . . . . . . . . . . . . . . 12 79 5.7. Deployed system . . . . . . . . . . . . . . . . . . . . . 13 80 5.8. Fault tolerance . . . . . . . . . . . . . . . . . . . . . 13 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 7.1. Accessibility . . . . . . . . . . . . . . . . . . . . . . 13 84 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 14 85 7.3. Data confidentiality . . . . . . . . . . . . . . . . . . 14 86 7.4. Privacy protection . . . . . . . . . . . . . . . . . . . 14 87 7.5. Robustness/resiliency . . . . . . . . . . . . . . . . . . 14 88 7.6. Network privacy . . . . . . . . . . . . . . . . . . . . . 14 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 9.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 The current Internet is a host-centric networking, where hosts are 98 uniquely identified with IP addresses and communication is possible 99 between any pair of hosts. Thus, information in the current Internet 100 is identified by the name of host where the information is stored. 101 In contrast to the host-centric networking, the primary communication 102 objects in Information-centric networking (ICN) are the named data 103 objects (NDOs) and they are uniquely identified by the location- 104 independent names. Thus, ICN aiming to the efficient dissemination 105 and retrieval of the NDOs in a global scale has been identified and 106 acknowledged as a promising technology for the future Internet 107 architecture to overcome the limitations of the current Internet such 108 as scalability and mobility.[Ahlgren] [Xylomenos]. ICN also has been 109 emerged as a candidate architecture for IoT environment since IoT 110 focuses on data and information rather than end-to-end communications 111 [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2]. 113 Since naming data independently from the current location where it is 114 stored is a primary concept of ICN, how to find the NDO using the 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 locators of 120 content producers or sources that can provide the content. 122 o Content discovery : 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 these three steps of ICN routing, this document focuses only on 128 the name resolution step which translates a content name to the 129 content locators. In addition, this document covers various possible 130 types of name resolution in ICN such as one name to another name, 131 name to manifest, name to locator, name to metadata, etc. 133 Thus, this document presents the overview of the Name Resolution 134 Service (NRS) approaches in ICN and discusses the functionalities and 135 the guidelines in designing the NRS for ICN. 137 2. Conventions and Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Name Resolution Service in ICN 145 The Name Resolution Service (NRS) in ICN is defined as the service 146 that provides the name resolution function for translating an object 147 name into some other information such as a locator, another name, 148 metadataetc. that is used for forwarding the object request. In 149 other words, the NRS is the service that shall be provided by ICN 150 infrastructure to help a consumer to reach a specific piece of 151 content, service, or host. The consumer provides the NRS with a 152 persistent name and the NRS returns a name or locator that represents 153 a current instance of the requested object. 155 The name resolution is a necessary process in ICN routing although 156 the name resolution either can be separated from the content 157 discovery as an explicit process or can be integrated with the 158 content discovery as an implicit process. The former is referred as 159 explicit name resolution approach, the latter is referred as name- 160 based routing approach in this document. 162 3.1. Explicit name resolution approach 164 The NRS could take the explicit name resolution approach to return 165 the client with the locators of the content, which will be used by 166 the underlying network as the identifier to route the client's 167 request to one of the producers. There are several ICN projects that 168 use the explicit name resolution approach such as DONA[Koponen], 169 PURSUIT [PURSUIT], NetInf [SAIL], MobilityFirst [MF], IDNet [Jung], 170 etc. 172 3.2. Name-based routing approach 174 The NRS could take the name-based routing approach, which integrates 175 the name resolution with the content request message routing as in 176 NDN [NDN]/CCN [CCN]. 178 In the case that the content request also specifies the reverse path, 179 as in NDN/CCN, the name resolution mechanism also determines the 180 routing path for the data. This adds a requirement on the name 181 resolution service to propagate request in a way that is consistent 182 with the subsequent data forwarding. Namely, the request must select 183 a path for the data based upon the finding the copy of the content, 184 but also properly delivering the data. 186 3.3. Hybrid approach 188 The NRS could also take hybrid approach which can perform the name- 189 based routing approach from the beginning. When it fails at certain 190 router, the router can go back to the explicit name resolution 191 approach. The alternative hybrid NRS approach also works, which can 192 perform explicit name resolution approach from the beginning to find 193 locators of routers. And then it can carry out the name-based 194 routing approach of the client's request. 196 A hybrid approach would combine name resolution as a subset of 197 routers on the path with some tunneling in between (say, across an 198 administrative domain) so that only a few of the nodes in the 199 architecture perform name resolution in the name-based routing 200 approach. 202 3.4. Comparisons of name resolution approaches 204 The following compares the explicit name resolution and the name- 205 based routing approaches from different aspects: 207 o Update message overhead : The update message overhead is due to 208 the change of content reachability, which may include content 209 caching or expiration, content producer mobility etc. The name- 210 based routing approach may require flooding parts of the network 211 for update propagation. In the worst case, the name-based routing 212 approach may flood the whole network (but mitigating techniques 213 may be used to scope the flooding). However, the explicit name 214 resolution approach only requires updating propagation in part of 215 the name resolution overlay. 217 o Resolution capability : The explicit name resolution approach can 218 guarantee the resolution of any content name in the network if it 219 is registered to the name resolution overlay. In the name-based 220 routing approach, content resolution depends on the flooding scope 221 of the content names (i.e. content publishing message and the 222 resulting name based routing tables). For example, when a content 223 is cached, the router may only notify this information to its 224 direct neighbors. Thus only those neighboring routers can build a 225 named based entry for this cached content. But if the neighboring 226 routers continue to propagate this information, the other nodes 227 are able to direct to this cached copy as well. 229 o Node failure impact : Nodes involved in the explicit name 230 resolution approach are the name resolution overlay servers (e.g. 231 Resolution Handlers in DONA), while the nodes involved in the 232 name-based routing approach are routers which route messages based 233 on locally maintained name-based routing tables (e.g. NDN 234 routers). Node failures in the explicit name resolution approach 235 may cause some content discovery to fail even though the content 236 is available. This problem does not exist in the name-based 237 routing approach because other alternative paths can be discovered 238 to bypass the failed ICN routers, given the assumption that the 239 network is still connected. 241 o Maintained databases : The storage usage for the explicit name 242 resolution approach is different from that of the name-based 243 routing approach. The explicit name resolution approach typically 244 needs to maintain two databases: name to locator mapping in the 245 name resolution overlay and routing tables in the routers on the 246 data forwarding plane. The name-based routing approach needs to 247 maintain different databases: name routing table and optionally 248 breadcrumbs for reverse routing of content back to the requester. 250 Additionally, some other intermediary step may be included in the 251 name resolution, namely the mapping of one name to other names, in 252 order to facilitate the retrieval of named content, by way of a 253 manifest [Westphal] [Mosko]. The manifest is resolved using one of 254 the two above approaches, and it may include further mapping of names 255 to content and location. The steps for name resolution then become: 256 first translate the manifest name into a location of a copy of the 257 manifest; the manifest includes further names of the content 258 components, and potentially locations for the content. The content 259 is then retrieved by using these names and/or location, potentially 260 resulting in additional name resolutions. 262 Thus, no matter which approach is taken by the NRS in ICN, the name 263 resolution is the essential function that shall be provided by the 264 ICN infrastructure. 266 4. Functionalities of NRS in ICN 268 This section presents the functionalities of NRS in ICN. 270 4.1. Support heterogeneous name types 272 In ICN, a name is used to identify data object and is bound to it 273 [RFC7927]. ICN requires uniqueness and persistency of the name of 274 data object to ensure the reachability of the object within a certain 275 scope and with proper authentication and trust management. There are 276 heterogeneous approaches to designing ICN naming schemes [Bari]. 277 Ideally, a name can include any form of identifier, which can be 278 flat, hierarchical, and human readable or non-readable. 280 Although there are diverse types of naming schemes proposed in 281 literature, they all need to provide basic functions for identifying 282 data object, supporting trust provenance, named data lookup and 283 routing. The NRS may combine the good aspects of different schemes. 284 Basically, the NRS should be able to support a generic naming schema 285 so that it can resolve any type of content name, irrespective of 286 whether it is flat or hierarchical. 288 In PURSUIT [PURSUIT], names are flat and the rendezvous functions are 289 defined for NRS, which is implemented by a set of Rendezvous Nodes 290 (RNs), the Rendezvous Network (RENE). Thus a name consisted of a 291 sequence of scope IDs and a single rendezvous ID is routed by RNs in 292 RENE. Thus, PURSUIT decouples name resolution and data routing, 293 where NRS is performed by the RENE. 295 In MobilityFirst [MF], a name called a global unique Identifier 296 (GUID) derived from a human-readable name via a global naming service 297 is flat typed 160-bits strings with self-certifying function. Thus, 298 MobilityFirst defines a global name resolution service (GNRS) which 299 resolves GUIDs to network addresses and decouples name resolution and 300 data routing as similar to PURSUIT. 302 In NetInf [Dannewitz], information objects are named using ni-naming 303 [RFC6920], which consist of an authority part and digest part 304 (content hash). The ni names can be flat as the authority part is 305 optional. Thus, the NetInf architecture also includes a Name 306 Resolution System (NRS) which can be used to resolve ni-names to 307 addresses in an underlying routable network layer. 309 In NDN [NDN] and CCN [CCN], names are hierarchical and may be similar 310 to URLs. Each name component can be anything, including a dotted 311 human-readable string or a hash value. NDN/CCN adopts the name based 312 routing approach. The NDN router forwards the request by doing the 313 longest-match lookup in the Forwarding Information Base (FIB) based 314 on the content name and the request is stored in the Pending Interest 315 Table (PIT). 317 4.2. Support producer mobility 319 ICN natively supports mobility management. Especially, consumer or 320 client mobility is handled by requesting the content again in case 321 the mobility or handover occurred before receiving the corresponding 322 content from the network. Since ICN can ensure that content 323 reception continues without any disruption in ICN application, 324 seamless mobility in consumer point of view can be easily supported. 326 However, producer or publisher mobility in ICN is complicated to 327 support. If a producer moves into a different authority domain or 328 network location, it would be difficult for the mobility management 329 update RIB and FIB entries in ICN routers with the new forwarding 330 path in a very short time. Therefore, various ICN architectures in 331 literatures have proposed to adopt NRS to achieve the producer or 332 publisher mobility, where NRS can be implemented in different ways 333 such as at rendezvous points and overlay mapping systems. 335 In NDN [Zhang2], for producer mobility support, rendezvous mechanisms 336 have been proposed to build interests rendezvous (RV) with data 337 generated by a mobile producer (MP). There can be classified two 338 approaches such as chase mobile producer and rendezvous data. 339 Regarding MP chasing, rendezvous acts as a mapping service that 340 provides the mapping from the name of the data produced by the MP to 341 the MP's current point of attachment (PoA) name. Alternatively, the 342 RV serves as a home agent like as IP mobility support, so the RV 343 enables consumer's interest message to tunnel towards the MP at the 344 PoA. Regarding rendezvous data, moving the data produced by the MP 345 have been hosting at data depot instead of forwarding interest 346 messages. Thus a consumer's interest message can be forwarded to 347 stationary place as called data rendezvous, so it would either return 348 the data or fetch it using another mapping solution. Therefore, RV 349 or other mapping functions are in the role of NRS in NDN. 351 In [Ravindran], forwarding-label (FL) object is referred to enable 352 identifier (ID) and locator (LID) namespaces to be split in ICN. 353 Generally, IDs are managed by applications, while locators are 354 managed by a network administrator, so that IDs are mapping to 355 heterogeneous name schemes and LIDs are mapping to network domains or 356 specific network elements. Thus the proposed FL object acts as a 357 locator (LID) and provides the flexibility to forward Interest 358 messages through mapping service between IDs and LIDs. Therefore, 359 the mapping service in control plane infrastructure can be considered 360 as NRS in this draft. 362 In MobilityFirst [MF], both consumer and publisher mobility can be 363 primarily handled by the global name resolution service (GNRS) which 364 resolves GUIDs to network addresses. Thus, the GNRS must be updated 365 for mobility support when a network attached object changes its point 366 of attachment, which differs from NDN/CCN. 368 In NetInf [Dannewitz], mobility is handled by the NRS in a very 369 similar way as done in MobilityFirst. 371 Besides the consumer and producer mobility, ICN also has to face 372 challenges to support the other dynamic features such as multi- 373 homing, migration, and replication of named resources such as 374 content, devices, and services. Therefore, NRS can help to support 375 these dynamic features. 377 4.3. Support scalable routing system 379 In ICN, name of data objects is used for routing by either name 380 resolution step or routing table lookup. Thus, routing information 381 for each data object should be maintained in routing base, such as 382 Routing Information Base (RIB) and Forwarding Information Base (FIB). 383 Since the number of data objects would be very large, the size of 384 information bases would be significantly large as well [RFC7927]. 386 The hierarchical namespace used in CCN [CCN] and NDN [NDN] 387 architectures reduces the size of these tables through name 388 aggregation and improves scalability of routing system. In a flat 389 naming scheme, on the other hand, it would aggravate the scalability 390 problem in routing system. The non-aggregated name prefixes injected 391 to the Default Route Free Zone (DFZ) of ICN would create more serious 392 scalability problem similar to the scalability issue of IP routing 393 system. Thus, NRS may play an important role in the reduction of the 394 routing scalability problem regardless of the types of namespaces. 396 In [Afanasyev], in order to address the routing scalability problem 397 in NDN's DFZ, a well-known concept of Map-and-Encap is applied to 398 provide a simple and secure namespace mapping solution. In the 399 proposed map-and-encap design, data whose name prefixes do not exist 400 in the DFZ forwarding table can be retrieved by a distributed mapping 401 system called NDNS, which maintains and lookups the mapping 402 information from a name to its globally routed prefixes, where NDNS 403 is a kind of NRS. 405 4.4. Support off-path caching 407 Caching in-network is considered to be a basic architectural 408 component of an ICN architecture. It may be used to provide a 409 Quality-of-Service (QoS) experience to users, reduce the overall 410 network traffic, prevent network congestion and Denial-of-Service 411 (DoS) attacks and increase availability. Caching approaches can be 412 categorized into off-path caching and on-path caching based on the 413 location of caches in relation to the forwarding path from a original 414 server to a consumer. Off-path caching, also referred as content 415 replication or content storing, aims to replicate content within a 416 network in order to increase availability, regardless of the 417 relationship of the location to the forwarding path. Thus, finding 418 off-path cached objects is not trivial in name based routing of ICN. 419 In order to support off-path caches, replicas are usually advertised 420 into a name-based routing system or into NRS. 422 In [Bayhan], a NRS used to find off-path copies in the network, which 423 may not be accessible via content discovery mechanisms. Such 424 capability is essential for an Autonomous System (AS) to avoid the 425 costly inter-AS traffic for external content, to yield higher 426 bandwidth efficiency for intra-AS traffic, and to decrease the data 427 access latency for a pleasant user experience. 429 4.5. Support nameless object 431 In CCNx 1.0 [Mosko2], the concept of "Nameless Objects" that are a 432 Content Object without a Name is introduced to provide a means to 433 move Content between storage replicas without having to rename or re- 434 sign the content objects for the new name. Nameless Objects can be 435 addressed by the ContentObjectHash that is to restrict Content Object 436 matching by using SHA-256 hash. 438 An Interest message would still carry a Name and a ContentObjectHash, 439 where a Name is used for routing, while a ContentObjectHash is used 440 for matching. However, on the reverse path, if the Content Object's 441 name is missing, it is a "Nameless Object" and only matches against 442 the ContentObjectHash. Therefore, a consumer needs to resolve proper 443 name and hashes through an outside system, which can be considered as 444 NRS. 446 4.6. Support manifest 448 In collection of data objects which were organized as large and file 449 like contents [FLIC], the manifests are used as data structures to 450 transport this information. Thus, the manifests may contain hash 451 digests of signed content objects or other manifests, so that large 452 content objects which represent large piece of application data can 453 be collected by using the manifest. 455 In order to request content objects, a consumer needs to know a 456 manifest root name to acquire the manifest. In case of FLIC, a 457 manifest name can be represented by a nameless root manifest, so that 458 outside system may be involved to give this information to the 459 consumer. Therefore, NRS can be considered as a kind of mapping 460 database system. 462 4.7. Support metadata 464 When resolving the name of a content object the NRS in addition to 465 returning a locator could return a rich set of metadata. The 466 metadata could include alternative object locations, supported object 467 transfer protocol(s), caching policy, security parameters, data 468 format, hash of object data, etc. The consumer could use this 469 metadata for selection of object transfer protocol, security 470 mechanism, egress interface, etc. An example of how metadata can be 471 used in this way is provided by the NEO ICN architecture [NEO]. 473 5. Design guidelines for NRS in ICN 475 This section presents the guidelines for designing NRS in ICN. 477 5.1. Resolution response time 479 The name resolution process should provide a response within a 480 reasonable amount of time. The response should be either a proper 481 mapping of the name to a copy of the content, or an error message 482 stating that no such file exists. If the name resolution does not 483 map to a location, the system may not issue any response, and the 484 client should set a timer when sending a request, so as to consider 485 the resolution incomplete when the timer expires. 487 The acceptable response delay should be of the order of a round trip 488 time between the client issuing the request and the NRS servers that 489 provides the response. While this RTT may be very greatly depending 490 on the proximity between the two end points, some upper bound should 491 be used. 493 The response time should be within the same order of magnitude for 494 most pairs of a client issuing a request, and the NRS server 495 responding to this request. 497 The response time should include all the steps of the resolution, 498 including potentially a hop-by-hop resolution or a hierarchical 499 forwarding of the resolution request. 501 5.2. Response accuracy 503 The NRS must provide an accurate response, namely a proper binding of 504 the requested name (or prefix) with a location. The response can be 505 either a (prefix, location) pair, or the actual forwarding of a 506 request to a node holding the content, which is then transmitted in 507 return. 509 The NRS must provide an up-to-date response, namely the NRS should be 510 updated within a reasonable time when new copies of the content are 511 being stored in the network. While every transient cache addition/ 512 eviction should not trigger an NRS update, some origin servers may 513 move and require the NRS to be updated. 515 The NRS must provide mechanisms to update the mapping of the content 516 with its location. Namely, the NRS must provide a mechanism for a 517 content owner to add new content, revoke old/dated/obsolete content, 518 and modify existing content. Any content update should then be 519 propagated through the NRS system within reasonable delay. 521 Content that is highly mobile may require to specify some type of 522 anchor that is kept at the NRS, instead of the content location. 524 5.3. Resolution guarantee 526 The NRS must ensure that the name resolution would be successful if 527 the name matching content exists in the network, regardless of its 528 popularity and number of cached copies existing in the network. 530 5.4. Resolution fairness 532 The NRS should provide this service for all content in a fair manner, 533 independently of the specific content properties (content producer, 534 content popularity, availability of copies, content format, etc.) 536 5.5. Scalability 538 The NRS system must scale up to support a very large user population 539 (including human users as well as machine-to-machine communications). 540 The system must be able to respond to a very large number of requests 541 per unit of time. Message forwarding and processing, routing table 542 building-up and name records propagation must be efficient and 543 scalable. 545 The NRS system must scale up with the number of pieces of content 546 (content names) and should be able to support a content catalog that 547 is extremely large. 549 The NRS system must be able to scale up, namely to add NRS servers to 550 the NRS system, in a way that is transparent to the users. Addition 551 of a new server should have limited impact on the other NRS servers 552 (or should have impact on only a small subset of the NRS servers). 554 The NRS system should support access from a heterogeneity of 555 connection methods and devices. In particular, the NRS system should 556 support access from constrained devices and interactions with the NRS 557 system should not be too costly. An IoT node for instance should be 558 able to access the NRS system as well as a more powerful node. 560 The NRS system should scale up in its responsiveness to the increased 561 request rate that is expected from applications such as IoT or M2M, 562 where data is being frequently generated and/or frequently requested. 564 5.6. Manageability 566 The NRS system must be manageable since some parts of the system may 567 grow or shrink dynamically and an NRS system node may be added or 568 deleted frequently. 570 The NRS may support an NRS management layer that allows for adding or 571 subtracting NRS nodes. The management layer should be able to infer 572 if the use of the NRS in some parts of the network is growing (or 573 shrinking). 575 5.7. Deployed system 577 The NRS system must be deployable since deployability is important 578 for a real world system. The NRS system must be deployable in 579 network edges and cores so that the consumers as well as ICN routers 580 can perform name resolution in a very low latency. 582 5.8. Fault tolerance 584 The NRS system must ensure resiliency in the event of NRS server 585 failures. The failure of a small subset of nodes should not impact 586 the NRS performance significantly. 588 After a NRS server fails, the NRS system must be able to recover and/ 589 or restore the name records stored in the NRS server. 591 6. IANA Considerations 593 There are no IANA considerations related to this document. 595 7. Security Considerations 597 Accessibility, authentication, confidentiality and privacy protection 598 are the concerns on security aspect of both the NRS server nodes and 599 mapping records stored in the NRS system. 601 7.1. Accessibility 603 The name records must have assigned with proper access rights such 604 that the information contained in the name mapping record would not 605 be revealed to unauthorized users. In other words, the NRS system 606 must be prevented from malicious users attempting to hijack or 607 corrupt the name mapping records. 609 The NRS may support access control for certain name records, so that 610 only users with the proper credential can access these record, and 611 these records would not be shared to unauthorized users. 613 The NRS may support authentication of the content producers to 614 determine that any location update/addition/removal that a content 615 producer is requesting is indeed valid and that the content producer 616 is authorized to modify this record. 618 The NRS should verify new mapping location that are being registered 619 so that it cannot be polluted with falsified information or invalid 620 records. 622 7.2. Authentication 624 The NRS must require authentication of new NRS nodes that register 625 themselves in the NRS system to ensure they are who they claim to be. 626 For example, it should detect an attacker attempting to act as a fake 627 NRS server to disrupt the NRS service, or to intercept some users' 628 data. 630 7.3. Data confidentiality 632 NRS must keep the data confidentiality to prevent a lot of sensitive 633 data from reaching unauthorized data requestor such as in IoT 634 environment. 636 NRS must keep meta-data confidential as well as usage to protect the 637 privacy of the users. For instance, a specific user's NRS requests 638 should not be shared outside the NRS system (with the exception of 639 legal intercept). 641 7.4. Privacy protection 643 When a private name mapping record is registered in the system, the 644 NRS system must support the privacy to avoid the information leaking. 645 Otherwise, unauthorized entity may disclose the privacy. 647 7.5. Robustness/resiliency 649 The NRS system should be resilient to denial of service attacks and/ 650 or other common attacks on the integrity of its system. The NRS 651 system should be resilient if a few attacked nodes are unable to 652 participate in the system. 654 7.6. Network privacy 656 The NRS node in a given subdomain should not leak information about 657 this domain (say, topology, number of nodes, number of clients, 658 number of requests) to nodes outside of this domain, except for 659 sharing the content that it is allowed to advertise, or for the 660 management protocols that it is supporting. 662 8. Acknowledgements 664 The authors would like to thank Ved Kafle for his valuable comments 665 and suggestions on this document. 667 9. References 669 9.1. Normative References 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, 673 DOI 10.17487/RFC2119, March 1997, 674 . 676 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 677 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 678 "Information-Centric Networking (ICN) Research 679 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 680 . 682 9.2. Informative References 684 [Ahlgren] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., 685 and B. Ohlman, "A Survey of Information-Centric 686 Networking", IEEE Communications Magarzine Vol.50, Issue 687 7, 2012. 689 [Xylomenos] 690 Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., 691 Tsilopoulos, C., Vasilako, X., Katsaros, K., and G. 692 Polyzos, "A Survey of Information-Centric Networking 693 Research,Communications Surveys and Tutorials", IEEE 694 Communications Surveys and Tutorials vol. 16, no. 2, 2014. 696 [Baccelli] 697 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 698 Wahlisch, "Information Centric Networking in the IoT: 699 Experiments with NDN in the Wild", ACM ICN 2014, 2014. 701 [Amadeo] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named 702 data networking for IoT: An architectural perspective", 703 European Conference on Networks and Communications 704 (EuCNC) , 2014. 706 [Quevedo] Quevedo, J., Corujo, D., and R. Aguiar, "A case for ICN 707 usage in IoT environments", IEEE GLOBECOM , 2014. 709 [Amadeo2] Amadeo, M. et al., "Information-centric networking for the 710 internet of things: challenges and opportunitiesve", IEEE 711 Network vol. 30, no. 2, July 2016. 713 [ID.Zhang2] 714 Zhang, Y., "Design Considerations for Applying ICN to 715 IoT", draft-zhang-icnrg-icniot-01 , June 2017. 717 [Koponen] Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim, 718 K., Shenker, S., and I. Stoica, "A Data-Oriented (and 719 Beyond) Network Architecture", ACM SIGCOMM 2007 pp. 720 181-192, 2007. 722 [PURSUIT] "FP7 PURSUIT project.", 723 http://www.fp7-pursuit.eu/PursuitWeb/ . 725 [SAIL] "FP7 SAIL project.", http://www.sail-project.eu/ . 727 [NDN] "NSF Named Data Networking project.", 728 http://www.named-data.net . 730 [CCN] "Content Centric Networking project.", 731 https://wiki.fd.io/view/Cicn . 733 [MF] "NSF Mobility First project.", 734 http://mobilityfirst.winlab.rutgers.edu/ . 736 [Jung] Jung, H. et al., "IDNet: Beyond All-IP Network", ETRI 737 Jouranl vol. 37, no. 5, October 2015. 739 [Jacobson] 740 Jacobson, V., Smetters, D., Thornton, J., Plass, M., 741 Briggs, N., and R. Braynard, "Networking Named Content", 742 ACM CoNEXT , 2009. 744 [Baid] Baid, A., Vu, T., and D. Raychaudhuri, "Comparing 745 Alternative Approaches for Networking of Named Objects in 746 the Future Internet", IEEE Workshop on Emerging Design 747 Choices in Name-Oriented Networking (NOMEN) , 2012. 749 [Bari] Bari, M., Chowdhury, S., Ahmed, R., Boutaba, R., and B. 750 Mathieu, "A Survey of Naming and Routing in Information- 751 Centric Networks", IEEE Communications Magazine Vol. 50, 752 No. 12, P.44-53, 2012. 754 [Rajahalme] 755 Rajahalme, J., Sarela, M., Visala, K., and J. Riihijarvi, 756 "On Name-based Inter-domain Routing", Computer 757 Networks Vol. 55, No. 4, P. 975-986, March 2011. 759 [Katsaros] 760 Katsaros, K., Fotiou, N., Vasilakos, X., Ververidis, C., 761 Tsilopoulos, C., Xylomenos, G., and G. Polyzos, "On Inter- 762 Domain Name Resolution for Information-Centric Networks", 763 Proc.IFIP-TC6 Networking Conference , 2012. 765 [ID.Wang] Wang, J., Li, S., and C. Wetphal, "Namespace Resolution in 766 Future Internet Architectures", draft-wang-fia- 767 namespace-01 , October 2015. 769 [ID.Zhang] 770 Zhang, X., Ravindran, R., Xie, H., and G. Wang, "PID: A 771 Generic Naming Schema for Information-centric Network", 772 draft-zhang-icnrg-pid-naming-scheme-03 , August 2013. 774 [D.Zhang] Zhang, D. and H. Liu, "Routing and Name Resolution in 775 Information-Centric Networks", 22nd International 776 Conference on Computer Communications and Networks 777 (ICCCN) , 2013. 779 [Sevilla] Sevilla, S., Mahadevan, P., and J. Garcia-Luna-Aceves, 780 "iDNS: Enabling Information Centric Networking Through The 781 DNS", Name Oriented Mobility (workshop co-located with 782 Infocom 2014) , 2014. 784 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 785 Destinations", RFC 1498, DOI 10.17487/RFC1498, August 786 1993, . 788 [oneM2M] "oneM2M Functional Architecture TS 0001.", 789 http://www.onem2m.org/technical/published-documents. . 791 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 792 Application Protocol (CoAP)", RFC 7252, 793 DOI 10.17487/RFC7252, June 2014, 794 . 796 [ID.Shelby] 797 Shelby, Z., "CoRE Resource Directory", draft-ietf-core- 798 resource-directory-10 , March 2017. 800 [CoRE] "Constrained RESTful Environments, CoRE", 801 https://datatracker.ietf.org/wg/core/charter/ , March 802 2013. 804 [Westphal] 805 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 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 813 Locator/ID Separation Protocol (LISP)", RFC 6830, 814 DOI 10.17487/RFC6830, January 2013, 815 . 817 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 818 Protocol (LISP) Map-Server Interface", RFC 6833, 819 DOI 10.17487/RFC6833, January 2013, 820 . 822 [RFC6920] Farrell , S., Kutscher, D., Dannewitz, C., Ohlman, B., 823 Keranen, A., and P. Hallam-Baker, "Naming Things with 824 Hashes", RFC6920, DOI 10.17487/RFC6920, 825 https://rfc-editor.org/rfc/rfc6920.txt , Apr. 2013. 827 [Zhang] Zhang, L. et al., "Named data networking", ACM SIGCOMM 828 Computer Communication Review vol. 44, no. 3, July 2014. 830 [Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data 831 Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES, 832 ALGORITHMS, AND APPLICATIONS(NOM) , 2016. 834 [Dannewitz] 835 Dannewitz, C. et al., "Network of Information (NetInf)-An 836 information centric networking architecture", Computer 837 Communications vol. 36, no. 7, April 2013. 839 [Seskar] Seskar, I., Nagaraja, K., Nelson, S., and D. Raychaudhuri, 840 "MobilityFirst Future Internet Architecture Project", 7th 841 Asian Internet Engineering Conference , November 2011. 843 [Dannewitz2] 844 Dannewitz, C., DAmbrosio, M., and V. Vercellone, 845 "Hierarchical DHT-based name resolution for Information- 846 Centric Networks", Computer Communications vol. 36, no. 7, 847 April 2013. 849 [Vu] Vu, T. et al., "DMap: A Shared Hosting Scheme for Dynamic 850 Identifier to Locator Mapping in the Global Internet", 851 IEEE 32nd International Conference on Distributed 852 Computing Systems , 2012. 854 [Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable 855 Name Resolution System for Information-Centric 856 Networking", ACM ICN , September 2015. 858 [Ravindran] 859 Ravindran, R. et al., "Forwarding-Label support in CCN 860 Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July 861 2017. 863 [Afanasyev] 864 Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to 865 Scale NDN Forwarding", IEEE Global Internet Symposium , 866 April 2015. 868 [Mosko2] Mosko, M., "Nameless Objects", , July 2015. 870 [Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path 871 Caching in Information-Centric Networks", ACM ICN , 872 September 2016. 874 [FLIC] Tschudin, C. and C. Wood, "File-Like ICN Collection 875 (FLIC)", draft-irtf-icnrg-flic-01, , June 2018. 877 [NEO] Eriksson, A. and A. M. Malik, "A DNS-based information- 878 centric network architecture open to multiple protocols 879 for transfer of data objects", 21st Conference on 880 Innovation in Clouds, Internet and Networks and Workshops 881 (ICIN), pp. 1-8, 2018. 883 Authors' Addresses 885 Jungha Hong 886 ETRI 887 218 Gajeong-ro, Yuseung-Gu 888 Daejeon 34129 889 Korea 891 Email: jhong@etri.re.kr 892 Tae-Wan You 893 ETRI 894 218 Gajeong-ro, Yuseung-Gu 895 Daejeon 34129 896 Korea 898 Email: twyou@etri.re.kr 900 Yong-Geun Hong 901 ETRI 902 218 Gajeong-ro, Yuseung-Gu 903 Daejeon 34129 904 Korea 906 Email: yghong@etri.re.kr 908 Lijun Dong 909 Huawei 910 10180 Telesis Court 911 San Diego, CA 92121 912 USA 914 Email: lijun.dong@huawei.com 916 Cedric Westphal 917 Huawei 918 2330 Central Expressway 919 Santa Clara, CA 95050 920 USA 922 Email: cedric.westphal@huawei.com 924 Borje Ohlman 925 Ericsson Research 926 S-16480 Stockholm 927 Sweden 929 Email: Borje.Ohlman@ericsson.com