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