idnits 2.17.1 draft-jhong-icnrg-nrs-requirements-04.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 2, 2018) is 2126 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 590, but not defined == Unused Reference: 'Jacobson' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'Baid' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'Bari' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'ID.Wang' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'Sevilla' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'RFC7252' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'ID.Shelby' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'CoRE' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'Westphal' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'Mosko' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 737, but no explicit reference was found in the text == Unused Reference: 'RFC6833' is defined on line 742, but no explicit reference was found in the text == Unused Reference: 'Zhang' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'Dannewitz' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'Seskar' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'Dannewitz2' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'Vu' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'Hong' is defined on line 774, 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 (~~), 24 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 ETRI 4 Intended status: Informational L. Dong 5 Expires: January 3, 2019 Huawei 6 T. You 7 ETRI 8 C. Westphal 9 Huawei 10 Y-G. Hong 11 ETRI 12 GQ. Wang 13 Huawei 14 J. Wang 15 City University Hong Kong 16 July 2, 2018 18 Requirements for Name Resolution Service in ICN 19 draft-jhong-icnrg-nrs-requirements-04 21 Abstract 23 This document discusses the motivation and requirements for Name 24 Resolution Service (NRS) in ICN. The NRS in ICN is to translate an 25 object name into some other information such as locator and another 26 name which is used for forwarding the object request. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 3, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 64 3. Name Resolution Service in ICN . . . . . . . . . . . . . . . 4 65 3.1. Standalone name resolution approach . . . . . . . . . . . 4 66 3.2. Name based routing approach . . . . . . . . . . . . . . . 4 67 3.3. Hybrid approach . . . . . . . . . . . . . . . . . . . . . 5 68 3.4. Comparisons of name resolution approaches . . . . . . . . 5 69 4. Motivation of NRS in ICN . . . . . . . . . . . . . . . . . . 6 70 4.1. Heterogeneous names in ICN . . . . . . . . . . . . . . . 6 71 4.2. Dynamism in ICN . . . . . . . . . . . . . . . . . . . . . 7 72 4.3. Routing system in ICN . . . . . . . . . . . . . . . . . . 8 73 4.4. Use cases of NRS . . . . . . . . . . . . . . . . . . . . 8 74 4.4.1. Flat name based routing support . . . . . . . . . . . 8 75 4.4.2. Producer mobility support . . . . . . . . . . . . . . 9 76 4.4.3. Scalable routing support . . . . . . . . . . . . . . 9 77 4.4.4. Off-Path cache support . . . . . . . . . . . . . . . 10 78 4.4.5. Nameless object support . . . . . . . . . . . . . . . 10 79 4.4.6. Menifest support . . . . . . . . . . . . . . . . . . 10 80 5. Requirements for NRS in ICN . . . . . . . . . . . . . . . . . 11 81 5.1. Requirements as a service . . . . . . . . . . . . . . . . 11 82 5.1.1. Delay sensitivity . . . . . . . . . . . . . . . . . . 11 83 5.1.2. Accuracy . . . . . . . . . . . . . . . . . . . . . . 11 84 5.1.3. Resolution guarantee . . . . . . . . . . . . . . . . 11 85 5.2. Requirements as a system . . . . . . . . . . . . . . . . 11 86 5.2.1. Scalability . . . . . . . . . . . . . . . . . . . . . 12 87 5.2.2. Manageability . . . . . . . . . . . . . . . . . . . . 12 88 5.2.3. Deployability . . . . . . . . . . . . . . . . . . . . 12 89 5.2.4. Fault tolerance . . . . . . . . . . . . . . . . . . . 12 90 5.3. Requirements on Security aspect . . . . . . . . . . . . . 12 91 5.3.1. Accessibility . . . . . . . . . . . . . . . . . . . . 12 92 5.3.2. Authentication . . . . . . . . . . . . . . . . . . . 12 93 5.3.3. Data confidentiality . . . . . . . . . . . . . . . . 13 94 5.3.4. Dat privacy . . . . . . . . . . . . . . . . . . . . . 13 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 97 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 99 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 100 9.2. Informative References . . . . . . . . . . . . . . . . . 13 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 The current Internet is a host-centric networking, where hosts are 106 uniquely identified with IP addresses and communication is possible 107 between any pair of hosts. Thus, information in the current Internet 108 is identified by the name of host where the information is stored. 109 In contrast to the host-centric networking, the primary communication 110 objects in Information-centric networking (ICN) are the named data 111 objects (NDOs) and they are uniquely identified by the location- 112 independent names. Thus, ICN aiming to the efficient dissemination 113 and retrieval of the NDOs in a global scale has been identified and 114 acknowledged as a promising technology for the future Internet 115 architecture to overcome the limitations of the current Internet such 116 as scalability, mobility, etc.[Ahlgren] [Xylomenos]. ICN also has 117 been emerged as a candidate architecture for IoT environment since 118 IoT focuses on data and information rather than end-to-end 119 communications [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2]. 121 Since naming data independently from the current location where it is 122 stored is a primary concept of ICN, how to find the NDO using the 123 location-independent name is one of the most important design 124 challenges in ICN. Such ICN routing may comprise three steps 125 [RFC7927] : 127 o Name resolution : matches/translates a content name to locators of 128 providers/sources that can provide the content. 130 o Content discovery : routes the content request towards the content 131 either based on its name or locator. 133 o Content delivery : transfers the content to the requester. 135 In three steps of ICN routing, this document focuses only the name 136 resolution step which translates a content name to its locators. In 137 addition, this document considers all other types of name resolution 138 in ICN such as name to name, name to manifest. 140 Thus, this document presents the definition of the Name Resolution 141 Service (NRS) in ICN and discusses the motivation and the 142 requirements in designing the NRS for ICN. 144 2. Conventions and Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 3. Name Resolution Service in ICN 152 The Name Resolution Service (NRS) in ICN is defined as the service 153 that provides the name resolution function translating an object name 154 into some other information such as locator and another name that is 155 used for forwarding the object request. In other words, the NRS is 156 the service that shall be provided by ICN infrastructure to help a 157 consumer to reach a specific piece of content, service, or host using 158 a persistent name when the name resolution is needed. 160 The name resolution is a necessary process in ICN routing although 161 the name resolution either can be separated from the content 162 discovery as a standalone process or can be integrated with the 163 content discovery as one combined process. The former is referred as 164 standalone name resolution approach, the latter is referred as name 165 based routing approach in this document. 167 3.1. Standalone name resolution approach 169 The NRS could take the standalone name resolution approach to return 170 the client with the locators of the content, which will be used by 171 the underlying network as the identifier to route the client's 172 request to one of the producers. There are several ICN projects that 173 use the standalone name resolution approach such as DONA[Koponen], 174 PURSUIT [PURSUIT], SAIL [SAIL], MobilityFirst [MF], IDNet [Jung], 175 etc. 177 3.2. Name based routing approach 179 The 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]/CCN [CCN]. 183 In the case that the content request also specifies the reverse path, 184 as in NDN/CCN, the name resolution mechanism also determines 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 the finding the copy of the content, 189 but also properly delivering the data. 191 3.3. Hybrid approach 193 The NRS could also take hybrid approach which can perform name based 194 routing approach from the beginning, when it fails at certain router, 195 the router can go back to the standalone name resolution approach. 196 The alternative hybrid NRS approach also works, which can perform 197 standalone name resolution approach to find locators of routers which 198 can carry out the name based routing of the client's request. 200 A hybrid approach would combine name resolution as a subset of 201 routers on the path with some tunneling in between (say, across an 202 administrative domain) so that only a few of the nodes in the 203 architecture perform name resolution in the name-based routing 204 approach. 206 3.4. Comparisons of name resolution approaches 208 The following compares the standalone name resolution and name based 209 routing approaches from different aspects: 211 o Update message overhead : The update message overhead is due to 212 the change of content reachability, which may include content 213 caching or expiration, content producer mobility etc. The name 214 based routing approach may require to flood part of the network 215 for update propagation. In the worst case, the name based routing 216 approach may flood the whole network (but mitigating techniques 217 may be used to scope the flooding). The standalone name 218 resolution approach only requires to update propagation in part of 219 the name resolution overlay. 221 o Resolution capability : The standalone name resolution approach 222 can guarantee the resolution of any content in the network if it 223 is registered to the name resolution overlay (assuming the content 224 is being broadcast in the overlay after it is registered). On the 225 other hand, the name based routing approach can only promise a 226 high probability of content resolution, depending on the flooding 227 scope of the content availability information (i.e. content 228 publishing message and name based routing table). 230 o Node failure impact : Nodes involved in the standalone name 231 resolution approach are the name resolution overlay servers (e.g. 232 Resolution Handlers in DONA), while the nodes involved in the name 233 based routing approach are routers which route messages based on 234 locally maintained name based routing tables (e.g. NDN routers). 235 Node failures in the standalone name resolution approach may cause 236 some content resolution to fail even though the content is 237 available. This problem does not exist in the name based routing 238 approach because other alternative paths can be discovered to 239 bypass the failed ICN routers, given the assumption that the 240 network is still connected. 242 o Maintained databases : The storage usage for the standalone name 243 resolution approach is different from that of the name based 244 routing approach. The standalone name resolution approach 245 typically needs to maintain two databases: name to locator mapping 246 in the name resolution overlay and routing tables in the routers 247 on the data forwarding plane. The name based routing approach 248 needs to maintain different databases: name routing table and 249 optionally breadcrumbs for reverse routing of content back to the 250 requester. 252 4. Motivation of NRS in ICN 254 This section presents the motivation and use cases of NRS in ICN. 256 4.1. Heterogeneous names in ICN 258 In ICN design, a name is used to identify an entity, such as named 259 data content, a device, an application, a service. ICN requires 260 uniqueness and persistency of the name of any entity to ensure the 261 reachability of the entity within certain scope and with proper 262 authentication and trust guarantees. The name does not change with 263 the mobility and multi-home of the corresponding entity. A client 264 can always use this name to retrieve the content from network and 265 verify the binding of the content and the name. 267 Ideally, a name can include any form of identifier, which can be 268 flat, hierarchical, and human readable or non-readable. 270 There are heterogeneous content naming schemes [ID.Zhang] [RFC1498] 271 and name resolution approaches from different ICN architectures. For 272 example: 274 o Names in DONA [Koponen] consist of the cryptographic hash of the 275 principal's public key P and a label L uniquely identifying the 276 information with respect to the principal. Name resolution in 277 DONA is provided by specialized servers called Resolution Handlers 278 (RHs). 280 o Content in PURSUIT [PURSUIT] is identified by a combination of a 281 scope ID and a rendezvous ID. The scope ID represents the 282 boundaries of a defined dissemination strategy for the content it 283 contain. The rendezvous ID is the actual identity for a 284 particular content. Name resolution in PURSUIT is handled by a 285 collection of Rendezvous Nodes (RNs), which are implemented as a 286 hierarchical Dynamic Hash Table (DHT)[Rajahalme] [Katsaros]. 288 o Names in NDN [NDN] and CCN [CCN] are hierarchical and may be 289 similar to URLs. Each name component can be anything, including a 290 dotted human-readable string or a hash value. NDN/CCN adopts the 291 name based routing. The NDN router forwards the request by doing 292 the longest-match lookup in the Forwarding Information Base (FIB) 293 based on the content name and the request is stored in the Pending 294 Interest Table (PIT). 296 o In MobilityFirst [MF], every network entity, content has a Global 297 Unique Identifier (GUID). GUIDs are flat 160-bit strings with no 298 semantic structure. Name Resolution in MobilityFirst is carried 299 out via a Global Name Resolution Service (GNRS). 301 Although the existing naming schemes are different, they all need to 302 provide basic functions for identifying a content, supporting trust 303 provenance, content lookup and routing. The NRS may combine the 304 advantages of different mechanisms. The NRS may be able to provide a 305 generic naming schema to resolve any type of content name, either it 306 is flat or hierarchical. 308 4.2. Dynamism in ICN 310 In ICN literature, it is said that mobility can be achieved in 311 fundamental feature of ICN. Especially, consumer or client mobility 312 can be achieved by allowing information requests to basic procedure 313 from different interfaces or through attachment point of the new 314 network. Moreover, seamless mobility service in ICN ensures that 315 content reception continues without any disruption in ICN 316 application, so in consumer point of view, seamless mobility can be 317 easily supported. 319 However, producer or publisher mobility in ICN is more complicated to 320 be supported. If a publisher moves into different authority domain 321 or network location, then the request for a content published by the 322 moving publisher with origin name would be hardly forwarded to the 323 moving publisher. Especially in a hierarchical name scheme, 324 publisher mobility support is much harder than in a flat name scheme 325 since the routing tables related in broad area should be updated 326 according to the publisher movement. Therefore, various ICN 327 literatures would adopt NRS to achieve the publisher mobility, where 328 NRS can be implemented in different ways such as rendezvous 329 mechanism, mapping, etc. 331 Besides mobility, ICN has challenge to support the dynamism features 332 like multi-homing, migration, and replication of named resources such 333 as content, devices, services, etc. and NRS may help to support the 334 dynamism features. 336 4.3. Routing system in ICN 338 In ICN, data objects must be identified by names regardless their 339 location or container [RFC7927] and the names are divided into two 340 types of schemes: hierarchical and flat namespaces. A hierarchical 341 scheme used in CCN and NDN architectures has a structure similar to 342 current URIs, where the hierarchy improves scalability of routing 343 system. It is because the hierarchy enables aggregation of the name 344 resulting in reducing the size of RIB or FIB as similar to IP routing 345 system. In a flat scheme, on the other hand, name routing is not 346 easy since names in a flat namespace cannot be aggregated anymore, 347 which would cause more the scalability problem in routing system. In 348 order to address such problem, a flat name can be resolved to some 349 information which is routable through NRS. 351 In ICN, application names identifying contents are used directly for 352 packet delivery, so ICN routers run a name-based routing protocol to 353 build name-based routing and forwarding tables. Regardless of name 354 scheme, if non-aggregated name prefixes are injected to the Default 355 Route Free Zone (DFZ) of ICN, then they would be driving the growth 356 of the DFZ routing table size, which is the same as the scalability 357 issue of IP routing. Thus a solution to keep the routing table size 358 under control is needed, which can be done by defining indirection 359 layer. 361 4.4. Use cases of NRS 363 This subsection describes NRS used in many other ways in ICN 364 literature. 366 4.4.1. Flat name based routing support 368 In PURSUIT [PURSUIT], names are flat and the rendezvous functions are 369 defined for NRS, which is implemented by a set of Rendezvous Nodes 370 (RNs), the Rendezvous Network (RENE). Thus a name consisted of a 371 sequence of scope IDs and a single rendezvous ID is routed by RNs in 372 RENE. Thus, PURSUIT decouples name resolution and data routing, 373 where NRS is performed by the RENE. 375 In MobilityFirst [MF], a name called a global unique Identifier 376 (GUID) derived from a human-readable name via a global naming service 377 is flat typed 160-bits strings with self-certifying function. Thus, 378 MobilityFirst defines a global name resolution service (GNRS) which 379 resolves GUIDs to network addresses and decouples name resolution and 380 data routing as similar to PURSUIT. 382 4.4.2. Producer mobility support 384 In NDN [Zhang2], for producer mobility support, rendezvous mechanisms 385 have been proposed to build interests rendezvous (RV) with data 386 generated by a mobile producer (MP). There can be classified two 387 approaches such as chase mobile producer and rendezvous data. 388 Regarding MP chasing, rendezvous acts as a mapping service that 389 provides the mapping from the name of the data produced by the MP to 390 the MP's current point of attachment (PoA) name. Alternatively, the 391 RV serves as a home agent like as IP mobility support, so the RV 392 enables consumer's interest message to tunnel towards the MP at the 393 PoA. Regarding rendezvous data, moving the data produced by the MP 394 have been hosting at data depot instead of forwarding interest 395 messages. Thus a consumer's interest message can be forwarded to 396 stationary place as called data rendezvous, so it would either return 397 the data or fetch it using another mapping solution. Therefore, RV 398 or other mapping functions are in the role of NRS in NDN. 400 In [Ravindran], forwarding-label (FL) object is referred to enable 401 identifier (ID) and locator (LID) namespaces to be split in ICN. 402 Generally, IDs are managed by applications, while locators are 403 managed by a network administrator, so that IDs are mapping to 404 heterogeneous name schemes and LIDs are mapping to network domains or 405 specific network elements. Thus the proposed FL object acts as a 406 locator (LID) and provides the flexibility to forward Interest 407 messages through mapping service between IDs and LIDs. Therefore, 408 the mapping service in control plane infrastructure can be considered 409 as NRS in this draft. 411 In MobilityFirst [MF], both consumer and publisher mobility can be 412 primarily handled by the global name resolution service (GNRS) which 413 resolves GUIDs to network addresses. Thus, the GNRS must be updated 414 for mobility support when a network attached object changes its point 415 of attachment, which differs from NDN/CCN. 417 4.4.3. Scalable routing support 419 In [Afanasyev], in order to address the routing scalability problem 420 in NDN's DFZ, a well-known concept of Map-and-Encap is applied to 421 provide a simple and secure namespace mapping solution. In the 422 proposed map-and-encap design, data whose name prefixes do not exist 423 in the DFZ forwarding table can be retrieved by a distributed mapping 424 system called NDNS, which maintains and lookups the mapping 425 information from a name to its globally routed prefixes, where NDNS 426 is a kind of NRS. 428 4.4.4. Off-Path cache support 430 Caching in-network is considered to be a basic architectural 431 component of an ICN architecture. It may be used to provide a 432 Quality-of-Service (QoS) experience to users, reduce the overall 433 network traffic, prevent network congestion and Denial-of-Service 434 (DoS) attacks and increase availability. Caching approaches can be 435 categorized into off-path caching and on-path caching based on the 436 location of caches in relation to the forwarding path from a original 437 server to a consumer. Off-path caching, also referred as content 438 replication or content storing, aims to replicate content within a 439 network in order to increase availability, regardless of the 440 relationship of the location to the forwarding path. Thus, finding 441 off-path cached objects is not trivial in name based routing of ICN. 442 In order to support off-path caches, replicas are usually advertised 443 into a name- based routing system or into NRS. 445 In [Bayhan], a NRS used to find off-path copies in the network, which 446 may not be accessible via content discovery mechanisms. Such 447 capability is essential for an Autonomous System (AS) to avoid the 448 costly inter-AS traffic for external content, to yield higher 449 bandwidth efficiency for intra-AS traffic, and to decrease the data 450 access latency for a pleasant user experience. 452 4.4.5. Nameless object support 454 In CCNx 1.0 [Mosko2], the concept of "Nameless Objects" that are a 455 Content Object without a Name is introduced to provide a means to 456 move Content between storage replicas without having to rename or re- 457 sign the content objects for the new name. Nameless Objects can be 458 addressed by the ContentObjectHash that is to restrict Content Object 459 matching by using SHA-256 hash. 461 An Interest message would still carry a Name and a ContentObjectHash, 462 where a Name is used for routing, while a ContentObjectHash is used 463 for matching. However, on the reverse path, if the Content Object's 464 name is missing, it is a "Nameless Object" and only matches against 465 the ContentObjectHash. Therefore, a consumer needs to resolve proper 466 name and hashes through an outside system, which can be considered as 467 NRS. 469 4.4.6. Menifest support 471 In collection of data objects which were organized as large and file 472 like contents [FLIC], the manifests are used as data structures to 473 transport this information. Thus, the manifests may contain hash 474 digests of signed content objects or other manifests, so that large 475 content objects which represent large piece of application data can 476 be collected by using the manifest. 478 In order to request content objects, a consumer needs to know a 479 manifest root name to acquire the manifest. In case of FLIC, a 480 manifest name can be represented by a nameless root manifest, so that 481 outside system may be involved to give this information to the 482 consumer. Therefore, NRS can be considered as a kind of mapping 483 database system. 485 5. Requirements for NRS in ICN 487 This section presents the requirements for designing NRS in ICN in 488 terms of service, system and security aspects, respectively. 490 5.1. Requirements as a service 492 This subsection presents the requirements for NRS as a service. 494 5.1.1. Delay sensitivity 496 The name resolution process provided by the NRS must be completed 497 within a minimum delay. If the name resolution takes too long, then 498 the content request packet may get dropped or it will yield the high 499 content retrieval time for content requestor. Thus, the content 500 retrieval time has to be content requestor-tolerant. 502 5.1.2. Accuracy 504 The NRS must provide accurate and up-to-date information on how to 505 discover the requested content with minimum overhead in propagating 506 the update information. For example, a content can be moved from one 507 domain to another domain due to the mobility of the producer, then 508 the old name record should be deleted from the NRS system and a new 509 name record should be added and updated with minimum delay. 511 5.1.3. Resolution guarantee 513 The NRS must ensure the name resolution success if the matching 514 content exists in the network, regardless of its popularity, number 515 of cached copies. 517 5.2. Requirements as a system 519 This subsection presents the requirements for NRS as a system. 521 5.2.1. Scalability 523 The NRS system must be extremely scalable to support a large number 524 of content objects as well as billions of users, who may access the 525 system through various connection methods and devices. Especially in 526 IoT applications, the data size is small but frequently generated by 527 sensors. Message forwarding and processing, routing table building- 528 up and name records propagation must be efficient and scalable. 530 5.2.2. Manageability 532 The NRS system must be manageable since some parts of the system may 533 grow or shrink dynamically and a NRS system node may be added or 534 deleted. 536 5.2.3. Deployability 538 The NRS system must be deployable since deployability is important 539 for a real world system. If the NRS system can be deployed from the 540 edges, then the deployment can be simplified. 542 5.2.4. Fault tolerance 544 The NRS system must ensure resilience to node failures. After a NRS 545 node fails, the NRS system must be able to restore the name records 546 stored in the NRS node. 548 5.3. Requirements on Security aspect 550 This subsection presents the requirements for NRS on security aspect 551 for both node and data in the NRS system. 553 5.3.1. Accessibility 555 The name records must have proper access rights such that the 556 information contained in the name record would not be revealed to 557 unauthorized users. In other words, The NRS system must be prevented 558 from the malicious users attempting to hijack or corrupt name 559 records. 561 5.3.2. Authentication 563 Users/nodes that register themselves in the NRS system must require 564 the authentication to ensure who claims to be. For example, the 565 attacker can act as a fake NRS server which causes disruption or 566 intercepts the data. 568 5.3.3. Data confidentiality 570 NRS must keep the data confidentiality to prevent a lot of sensitive 571 data from reaching unauthorized data requestor such as in IoT 572 environment. 574 5.3.4. Dat privacy 576 When a private data is registered in the system, the NRS system must 577 support the privacy to avoid the information leaking. Otherwise, 578 unauthorized entity may disclose the privacy. 580 6. IANA Considerations 582 There are no IANA considerations related to this document. 584 7. Security Considerations 586 [TBD] 588 8. Acknowledgements 590 [TBD] 592 9. References 594 9.1. Normative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 602 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 603 "Information-Centric Networking (ICN) Research 604 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 605 . 607 9.2. Informative References 609 [Ahlgren] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., 610 and B. Ohlman, "A Survey of Information-Centric 611 Networking", IEEE Communications Magarzine Vol.50, Issue 612 7, 2012. 614 [Xylomenos] 615 Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., 616 Tsilopoulos, C., Vasilako, X., Katsaros, K., and G. 617 Polyzos, "A Survey of Information-Centric Networking 618 Research,Communications Surveys and Tutorials", IEEE 619 Communications Surveys and Tutorials vol. 16, no. 2, 2014. 621 [Baccelli] 622 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 623 Wahlisch, "Information Centric Networking in the IoT: 624 Experiments with NDN in the Wild", ACM ICN 2014, 2014. 626 [Amadeo] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named 627 data networking for IoT: An architectural perspective", 628 European Conference on Networks and Communications 629 (EuCNC) , 2014. 631 [Quevedo] Quevedo, J., Corujo, D., and R. Aguiar, "A case for ICN 632 usage in IoT environments", IEEE GLOBECOM , 2014. 634 [Amadeo2] Amadeo, M. et al., "Information-centric networking for the 635 internet of things: challenges and opportunitiesve", IEEE 636 Network vol. 30, no. 2, July 2016. 638 [ID.Zhang2] 639 Zhang, Y., "Design Considerations for Applying ICN to 640 IoT", draft-zhang-icnrg-icniot-01 , June 2017. 642 [Koponen] Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim, 643 K., Shenker, S., and I. Stoica, "A Data-Oriented (and 644 Beyond) Network Architecture", ACM SIGCOMM 2007 pp. 645 181-192, 2007. 647 [PURSUIT] "FP7 PURSUIT project.", 648 http://www.fp7-pursuit.eu/PursuitWeb/ . 650 [SAIL] "FP7 SAIL project.", http://www.sail-project.eu/ . 652 [NDN] "NSF Named Data Networking project.", 653 http://www.named-data.net . 655 [CCN] "Content Centric Networking project.", 656 https://wiki.fd.io/view/Cicn . 658 [MF] "NSF Mobility First project.", 659 http://mobilityfirst.winlab.rutgers.edu/ . 661 [Jung] Jung, H. et al., "IDNet: Beyond All-IP Network", ETRI 662 Jouranl vol. 37, no. 5, October 2015. 664 [Jacobson] 665 Jacobson, V., Smetters, D., Thornton, J., Plass, M., 666 Briggs, N., and R. Braynard, "Networking Named Content", 667 ACM CoNEXT , 2009. 669 [Baid] Baid, A., Vu, T., and D. Raychaudhuri, "Comparing 670 Alternative Approaches for Networking of Named Objects in 671 the Future Internet", IEEE Workshop on Emerging Design 672 Choices in Name-Oriented Networking (NOMEN) , 2012. 674 [Bari] Bari, M., Chowdhury, S., Ahmed, R., Boutaba, R., and B. 675 Mathieu, "A Survey of Naming and Routing in Information- 676 Centric Networks", IEEE Communications Magazine Vol. 50, 677 No. 12, P.44-53, 2012. 679 [Rajahalme] 680 Rajahalme, J., Sarela, M., Visala, K., and J. Riihijarvi, 681 "On Name-based Inter-domain Routing", Computer 682 Networks Vol. 55, No. 4, P. 975-986, March 2011. 684 [Katsaros] 685 Katsaros, K., Fotiou, N., Vasilakos, X., Ververidis, C., 686 Tsilopoulos, C., Xylomenos, G., and G. Polyzos, "On Inter- 687 Domain Name Resolution for Information-Centric Networks", 688 Proc.IFIP-TC6 Networking Conference , 2012. 690 [ID.Wang] Wang, J., Li, S., and C. Wetphal, "Namespace Resolution in 691 Future Internet Architectures", draft-wang-fia- 692 namespace-01 , October 2015. 694 [ID.Zhang] 695 Zhang, X., Ravindran, R., Xie, H., and G. Wang, "PID: A 696 Generic Naming Schema for Information-centric Network", 697 draft-zhang-icnrg-pid-naming-scheme-03 , August 2013. 699 [D.Zhang] Zhang, D. and H. Liu, "Routing and Name Resolution in 700 Information-Centric Networks", 22nd International 701 Conference on Computer Communications and Networks 702 (ICCCN) , 2013. 704 [Sevilla] Sevilla, S., Mahadevan, P., and J. Garcia-Luna-Aceves, 705 "iDNS: Enabling Information Centric Networking Through The 706 DNS", Name Oriented Mobility (workshop co-located with 707 Infocom 2014) , 2014. 709 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 710 Destinations", RFC 1498, DOI 10.17487/RFC1498, August 711 1993, . 713 [oneM2M] "oneM2M Functional Architecture TS 0001.", 714 http://www.onem2m.org/technical/published-documents. . 716 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 717 Application Protocol (CoAP)", RFC 7252, 718 DOI 10.17487/RFC7252, June 2014, 719 . 721 [ID.Shelby] 722 Shelby, Z., "CoRE Resource Directory", draft-ietf-core- 723 resource-directory-10 , March 2017. 725 [CoRE] "Constrained RESTful Environments, CoRE", 726 https://datatracker.ietf.org/wg/core/charter/ , March 727 2013. 729 [Westphal] 730 Westphal, C. and E. Demirors, "An IP-based Manifest 731 Architecture for ICN", ACM ICN , 2015. 733 [Mosko] Mosko, M., Scott, G., Solis, I., and C. Wood, "CCNx 734 Manifest Specification", draft-wood-icnrg- 735 ccnxmanifests-00 , July 2015. 737 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 738 Locator/ID Separation Protocol (LISP)", RFC 6830, 739 DOI 10.17487/RFC6830, January 2013, 740 . 742 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 743 Protocol (LISP) Map-Server Interface", RFC 6833, 744 DOI 10.17487/RFC6833, January 2013, 745 . 747 [Zhang] Zhang, L. et al., "Named data networking", ACM SIGCOMM 748 Computer Communication Review vol. 44, no. 3, July 2014. 750 [Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data 751 Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES, 752 ALGORITHMS, AND APPLICATIONS(NOM) , 2016. 754 [Dannewitz] 755 Dannewitz, C. et al., "Network of Information (NetInf)-An 756 information centric networking architecture", Computer 757 Communications vol. 36, no. 7, April 2013. 759 [Seskar] Seskar, I., Nagaraja, K., Nelson, S., and D. Raychaudhuri, 760 "MobilityFirst Future Internet Architecture Project", 7th 761 Asian Internet Engineering Conference , November 2011. 763 [Dannewitz2] 764 Dannewitz, C., DAmbrosio, M., and V. Vercellone, 765 "Hierarchical DHT-based name resolution for Information- 766 Centric Networks", Computer Communications vol. 36, no. 7, 767 April 2013. 769 [Vu] Vu, T. et al., "DMap: A Shared Hosting Scheme for Dynamic 770 Identifier to Locator Mapping in the Global Internet", 771 IEEE 32nd International Conference on Distributed 772 Computing Systems , 2012. 774 [Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable 775 Name Resolution System for Information-Centric 776 Networking", ACM ICN , September 2015. 778 [Ravindran] 779 Ravindran, R. et al., "Forwarding-Label support in CCN 780 Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July 781 2017. 783 [Afanasyev] 784 Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to 785 Scale NDN Forwarding", IEEE Global Internet Symposium , 786 April 2015. 788 [Mosko2] Mosko, M., "Nameless Objects", , July 2015. 790 [Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path 791 Caching in Information-Centric Networks", ACM ICN , 792 September 2016. 794 [FLIC] Tschudin, C. and C. Wood, "File-Like ICN Collection 795 (FLIC)", draft-irtf-icnrg-flic-01, , June 2018. 797 Authors' Addresses 798 Jungha Hong 799 ETRI 800 218 Gajeong-ro, Yuseung-Gu 801 Daejeon 34129 802 Korea 804 Phone: +82 42 860 0926 805 Email: jhong@etri.re.kr 807 Lijun Dong 808 Huawei 809 10180 Telesis Court 810 San Diego, CA 92121 811 USA 813 Email: lijun.dong@huawei.com 815 Tae-Wan You 816 ETRI 817 218 Gajeong-ro, Yuseung-Gu 818 Daejeon 34129 819 Korea 821 Phone: +82 42 860 0642 822 Email: twyou@etri.re.kr 824 Cedric Westphal 825 Huawei 826 2330 Central Expressway 827 Santa Clara, CA 95050 828 USA 830 Email: cedric.westphal@huawei.com 832 Yong-Geun Hong 833 ETRI 834 218 Gajeong-ro, Yuseung-Gu 835 Daejeon 34129 836 Korea 838 Phone: +82 42 860 6557 839 Email: yghong@etri.re.kr 840 GQ Wang 841 Huawei 842 2330 Central Expressway 843 Santa Clara, CA 95050 844 USA 846 Email: gq.wang@huawei.com 848 Jianping Wang 849 City University Hong Kong 851 Email: jianwang@cityu.edu.hk