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