idnits 2.17.1 draft-jhong-icnrg-nrs-requirements-01.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 : ---------------------------------------------------------------------------- ** There are 49 instances of too long lines in the document, the longest one being 62 characters in excess of 72. 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 has text resembling RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2482 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 7929' is mentioned on line 163, but not defined == Missing Reference: 'TBD' is mentioned on line 675, but not defined == Missing Reference: 'RFC 7927' is mentioned on line 357, but not defined == Unused Reference: 'RFC7927' is defined on line 690, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 698, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 704, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 708, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 767, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 787, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 790, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6830 (ref. '26') (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 6833 (ref. '27') (Obsoleted by RFC 9301) == Outdated reference: A later version (-01) exists of draft-zhang-icnrg-icniot-00 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ICNRG J. Hong 2 Internet-Draft ETRI 3 Intended status: Informational Lijun Dong 4 Expires: January 4, 2018 Huawei 5 T. You 6 ETRI 7 Cedric Westphal 8 Huawei 9 Y-G. Hong 10 ETRI 11 GQ Wang 12 Huawei 13 Jianping Wang 14 City University Hong Kong 15 July 3, 2017 17 Requirements for Name Resolution Service in ICN 18 draft-jhong-icnrg-nrs-requirements-01.txt 20 Abstract 22 This document discusses the motivation and requirements for Name 23 Resolution Service (NRS) in ICN. The NRS in ICN is to translate an 24 object name into some other information such as locator and another 25 name which is used for forwarding the object request. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 4, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction .............................................................. 3 62 2. Conventions and terminology ...................................... 5 63 3. Name Resolution Service in ICN .................................. 5 64 4. Motivation of NRS in ICN ............................................ 8 65 4.1. Handling Heterogeneous Names in ICN ................... 8 66 4.2. Handling Dynamism in ICN ..................................... 9 67 4.3. Use cases of NRS ................................................ 9 68 4.3.1. Flat Name routing support ................................ 9 69 4.3.2. Publisher Mobility support ............................... 10 70 4.3.3. Scalable Routing support ................................ 11 71 4.3.4. Nameless object support ............................... 12 72 5. Requirements for NRS in ICN ...................................... 12 73 5.1. Service aspect .................................................... 12 74 5.1.1. Delay sensitivity ............................................. 12 75 5.1.2. Time transiency ............................................. 13 76 5.1.3. Resolution guarantee ...................................... 13 77 5.1.4. Accuracy ...................................................... 13 78 5.2. System aspects ................................................... 13 79 5.2.1. Scalability .................................................. 13 80 5.2.2. Fault tolerance ............................................... 14 81 5.2.3. Minimum inter-domain traffic ........................... 14 82 5.2.4. Manageability .......................................... 14 83 5.2.5. Deployability ......................................... 14 84 5.2.6. Interoperability .......................................... 15 85 5.3. Security aspect ................................................... 15 86 5.3.1. Accessibility .................................................. 15 87 5.3.2. Authentication ................................................ 16 88 5.3.3. Data confidentiality ......................................... 16 89 5.3.4. Privacy ......................................................... 16 90 6. Security Considerations .............................................. 16 91 7. IANA Considerations .................................................. 16 92 8. References ............................................................... 17 93 8.1. Normative References ........................................ 17 94 8.2. Informative References ........................................ 17 96 1. Introduction 98 The current Internet is a host-centric networking, where hosts are 99 uniquely identified with IP addresses and communication is possible 100 between any pair of hosts. Thus, information in the current Internet 101 is identified by the name of host where the information is stored. 102 In contrast to the host-centric networking, the primary 103 communication objects in Information-centric networking (ICN) are 104 the named data objects (NDOs) and they are uniquely identified by 105 the location-independent names. Thus, ICN aiming to the efficient 106 dissemination and retrieval of the NDOs in a global scale has been 107 identified and acknowledged as a promising technology for the future 108 Internet architecture to overcome the limitations of the current 109 Internet such as scalability, mobility, etc.[28][29] 111 ICN also has been emerged as a candidate architecture for IoT 112 environment since IoT focuses on data and information rather than 113 end-to-end communications [30][31][32]. In addition, the following 114 ICN features are fulfilling well the architectural requirements of 115 IoT such as naming, name resolution, scalability, resource 116 constraints, mobility, caching, security, privacy, etc.[33][34]: 118 - Naming of data, devices, and services independently from their 119 locations 121 - Distributed caching and processing 123 - Decoupling between sender and receiver 125 - Mobility support 127 - Authentication and verification of content 129 Since naming data independently from the current location where it 130 is stored is a primary concept of ICN, how to find the NDO using the 131 location-independent name is one of the most important design 132 challenges in ICN. There are several projects such as DONA[4], 133 PURSUIT[5], SAIL[6], MobilityFirst[9], and IDNet[35] which use the 134 name resolution step to discover the NDO using the location- 135 independent name. 137 The name resolution also can be used to address the routing 138 scalability problem such as in NDN [38] and to support efficiently a 139 flat name such as self-certifying identifier [5][9] as well as to 140 support the producer mobility. 142 Thus, in this document, we give the definition of the Name 143 Resolution Service (NRS) in ICN and discuss the motivation and the 144 requirements in designing the NRS for ICN. 146 2. Conventions and Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 149 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 151 3. Name Resolution Service in ICN 153 The Name Resolution Service (NRS) in ICN is defined as the service 154 that provides the name resolution function translating an object 155 name into some other information such as locator and another name 156 that is used for forwarding the object request. In other words, the 157 NRS is the service that shall be provided by ICN infrastructure to 158 help a consumer to reach a specific piece of content, service, or 159 host using a persistent name when the NRS is needed. 161 The name resolution is defined as the first step in ICN routing 162 along with the content request routing and content delivery as the 163 second and the third steps, respectively [RFC 7929]. 165 - Name resolution[11][12][14][15][17][18]: matches/translates a 166 content name to locators of providers/sources that can provide 167 the content. 169 - Content request routing: routes the content request towards the 170 content either based on its name or locator. The process of name 171 resolution and content request routing can be integrated. If 172 integrated, the content request is routed by name, such as in 173 NDN[7]/CCN[8]. If not integrated, the content request is routed 174 by the locator obtained from the previous name resolution step, 175 such as in DONA[4], PURSUIT[5], SAIL[6], MobilityFirst[9], 176 IDNet[35]. 178 - Content delivery: constructs a path for transferring the 179 content to the requester. In the integrated approach, content 180 can be routed using breadcrumbs left by the request to define a 181 reverse path, or by some other mechanism, such as including a 182 locator for the requester in the content request. In the 183 uncombined approach, the content can be routed from the provider 184 back to the request through an independent path. 186 Thus, the name resolution is a necessary process in ICN routing 187 although the name resolution either can be separated from the 188 content request routing as a standalone process or can be integrated 189 with the content request routing as one combined process. The former 190 is referred as standalone name resolution approach, the latter is 191 referred as name based routing approach in this document. 193 The following compares the standalone name resolution and name based 194 routing approaches from different aspects: 196 - Update message overhead: The update message overhead is due to 197 the change of content reachability, which may include content 198 caching or expiration, content producer mobility etc. The name 199 based routing approach may require to flood part of the network 200 for update propagation. In the worst case, the name based routing 201 approach may flood the whole network (but mitigating techniques 202 may be used to scope the flooding). The standalone name 203 resolution approach only requires to update propagation in part 204 of the name resolution overlay. 206 - Resolution capability: The standalone name resolution approach 207 can guarantee the resolution of any content in the network if it 208 is registered to the name resolution overlay (assuming the 209 content is being broadcast in the overlay after it is 210 registered). On the other hand, the name based routing approach 211 can only promise a high probability of content resolution, 212 depending on the flooding scope of the content availability 213 information (i.e. content publishing message and name based 214 routing table). 216 - Node failure impact: Nodes involved in the standalone name 217 resolution approach are the name resolution overlay servers (e.g. 218 Resolution Handlers in DONA), while the nodes involved in the 219 name based routing approach are routers which route messages 220 based on locally maintained name based routing tables (e.g. NDN 221 routers). Node failures in the standalone name resolution 222 approach may cause some content resolution to fail even though 223 the content is available. This problem does not exist in the name 224 based routing approach because other alternative paths can be 225 discovered to bypass the failed ICN routers, given the assumption 226 that the network is still connected. 228 - Maintained databases: The storage usage for the standalone name 229 resolution approach is different from that of the name based 230 routing approach. The standalone name resolution approach 231 typically needs to maintain two databases: name to locator 232 mapping in the name resolution overlay and routing tables in the 233 routers on the data forwarding plane. The name based routing 234 approach needs to maintain different databases: name routing 235 table and optionally breadcrumbs for reverse routing of content 236 back to the requester. 238 The NRS could take the standalone name resolution approach to return 239 the client with the locators of the content, which will be used by 240 the underlying network as the identifier to route the client's 241 request to one of the producers. There are several ICN projects that 242 use the standalone name resolution approach such as DONA[4], 243 PURSUIT[5], SAIL[6], MobilityFirst[9], IDNet[35], etc. 245 The NRS could take the name based routing approach, which integrates 246 the name resolution with the content request message routing as in 247 NDN[7]/CCN[8]. 249 In the case that the content request also specifies the reverse 250 path, as in NDN/CCN, the name resolution mechanism also determines 251 the routing path for the data. This adds a requirement on the name 252 resolution service to propagate request in a way that is consistent 253 with the subsequent data forwarding. Namely, the request must select 254 a path for the data based upon the finding the copy of the content, 255 but also properly delivering the data. 257 The NRS could also take hybrid approach which can perform name based 258 routing approach from the beginning, when it fails at certain 259 router, the router can go back to the standalone name resolution 260 approach. The alternative hybrid NRS approach also works, which can 261 perform standalone name resolution approach to find locators of 262 routers which can carry out the name based routing of the client's 263 request. 265 A hybrid approach would combine name resolution as a subset of 266 routers on the path with some tunneling in between (say, across an 267 administrative domain) so that only a few of the nodes in the 268 architecture perform name resolution in the name-based routing 269 approach. 271 Additionally, some other intermediary step may be included in the 272 name resolution, namely the mapping of one name to other names, in 273 order to facilitate the retrieval of named content, by way of a 274 manifest[24][25]. The manifest is resolved using one of the two 275 above approaches, and it may include further mapping of names to 276 content and location. The steps for name resolution then become: 277 first translate the manifest name into a location of a copy of the 278 manifest; the manifest includes further names of the content 279 components, and potentially locations for the content. The content 280 is then retrieved by using these names and/or location, potentially 281 resulting in additional name resolutions. 283 Thus, no matter which approach is taken by the NRS in ICN, the name 284 resolution is the essential function that shall be provided by the 285 ICN infrastructure. 287 4. Motivation of NRS in ICN 289 In this section, we discuss the motivation and use cases of NRS in 290 ICN. 292 4.1. Handling Heterogeneous Names in ICN 294 In ICN design, a name is used to identify an entity, such as named 295 data content, a device, an application, a service. ICN requires 296 uniqueness and persistency of the name of any entity to ensure the 297 reachability of the entity within certain scope and with proper 298 authentication and trust guarantees. The name does not change with 299 the mobility and multi-home of the corresponding entity. A client 300 can always use this name to retrieve the content from network and 301 verify the binding of the content and the name. 303 Ideally, a name can include any form of identifier, which can be 304 flat, hierarchical, and human readable or non-readable. 306 There are heterogeneous content naming schemes[16][19] and name 307 resolution approaches from different ICN architectures. For example: 309 - Names in DONA[4] consist of the cryptographic hash of the 310 principal's public key P and a label L uniquely identifying the 311 information with respect to the principal. Name resolution in DONA 312 is provided by specialized servers called Resolution Handlers (RHs). 314 - Content in PURSUIT[5] is identified by a combination of a scope ID 315 and a rendezvous ID. The scope ID represents the boundaries of a 316 defined dissemination strategy for the content it contain. The 317 rendezvous ID is the actual identity for a particular content. Name 318 resolution in PURSUIT is handled by a collection of Rendezvous Nodes 319 (RNs), which are implemented as a hierarchical Dynamic Hash Table 320 (DHT)[13][14]. 322 - Names in NDN/CCN[8][10] are hierarchical and may be similar to 323 URLs. Each name component can be anything, including a dotted human- 324 readable string or a hash value. NDN/CCN adopts the name based 325 routing. The NDN router forwards the request by doing the longest- 326 match lookup in the Forwarding Information Base (FIB) based on the 327 content name and the request is stored in the Pending Interest Table 328 (PIT). 330 - In MobilityFirst[9], every network entity, content has a Global 331 Unique Identifier (GUID). GUIDs are flat 160-bit strings with no 332 semantic structure. Name Resolution in MobilityFirst all is carried 333 out via a Global Name Resolution Service (GNRS). 335 Although the existing naming schemes are different, they all need to 336 provide basic functions for identifying a content, supporting trust 337 provenance, content lookup and routing. The NRS may combine the 338 advantages of different mechanisms. The NRS may be able to provide a 339 generic naming schema to resolve any type of content name, either it 340 is flat or hierarchical. 342 4.2. Handling Dynamism in ICN 344 ICN has challenge to support the dynamism features like mobility, 345 multi-homing, migration, and replication of named resources such as 346 content, devices, services, etc. and the NRS can help it. 348 [TBD] 350 4.3. Use cases of NRS 352 In this section, we describe usages of NRS in the ICN literature. 354 4.3.1. Flat Name routing support 356 In ICN, data objects must be identified by names regardless their 357 location or container [RFC 7927] and the names are divided into two 358 types of schemes: hierarchical and flat namespaces. A hierarchical 359 scheme used in CCN and NDN architectures has a structure similar to 360 current URIs, where the hierarchy improves scalability of routing 361 system. It is because the hierarchy enables aggregation of the name 362 resulting in reducing the size of RIB or FIB as similar to IP 363 routing system. 365 In a flat scheme, on the other hand, name routing is not easy since 366 names in a flat namespace cannot be aggregated anymore, which would 367 cause more the scalability problem in routing system. In order to 368 address such problem, a flat name is resolved to some information 369 which is routable through NRS or a sort of NRS in various ICN 370 literatures. 372 In PURSUIT [5], names are flat and the rendezvous functions are 373 defined for NRS, which is implemented by a set of Rendezvous Nodes 374 (RNs), the Rendezvous Network (RENE). Thus a name consisted of a 375 sequence of scope IDs and a single rendezvous ID is routed by RNs in 376 RENE. Thus, PURSUIT decouples name resolution and data routing, 377 where NRS is performed by the RENE. 379 In MobilityFirst [9], a name called a global unique Identifier 380 (GUID) derived from a human-readable name via a global naming 381 service is flat typed 160-bits strings with self-certifying 382 function. Thus, MobilityFirst defines a global name resolution 383 service (GNRS) which resolves GUIDs to network addresses and 384 decouples name resolution and data routing as similar to PURSUIT. 386 4.3.2. Publisher Mobility support 388 In ICN literature, it is said that mobility can be achieved in 389 fundamental feature of ICN. Especially, consumer or client mobility 390 can be achieved by allowing information requests to basic procedure 391 from different interfaces or through attachment point of the new 392 network. Moreover, seamless mobility service in ICN ensures that 393 content reception continues without any disruption in ICN 394 application, so in consumer point of view, seamless mobility can be 395 easily supported. 397 However, producer or publisher mobility in ICN is more complicated 398 to be supported. If a publisher moves into different authority 399 domain or network location, then the request for a content published 400 by the moving publisher with origin name would be hardly forwarded 401 to the moving publisher. Especially in a hierarchical name scheme, 402 publisher mobility support is much harder than in a flat name scheme 403 since the routing tables related in broad area should be updated 404 according to the publisher movement. Therefore, various ICN 405 literatures would adopt NRS to achieve the publisher mobility, where 406 NRS can be implemented in different ways such as rendezvous 407 mechanism, mapping, etc. 409 In NDN, for publisher mobility support, rendezvous mechanisms have 410 been proposed to build interests rendezvous (RV) with data generated 411 by a mobile producer (MP) [36]. There can be classified two 412 approaches such as chase mobile producer and rendezvous data. 413 Regarding MP chasing, rendezvous acts as a mapping service that 414 provides the mapping from the name of the data produced by the MP to 415 the MP's current point of attachment (PoA) name. Alternatively, the 416 RV serves as a home agent like as IP mobility support, so the RV 417 enables consumer's interest message to tunnel towards the MP at the 418 PoA. Regarding rendezvous data, moving the data produced by the MP 419 have been hosting at data depot instead of forwarding interest 420 messages. Thus a consumer's interest message can be forwarded to 421 stationary place as called data rendezvous, so it would either 422 return the data or fetch it using another mapping solution. 423 Therefore, RV or other mapping functions are in the role of NRS in 424 NDN. 426 In [37], forwarding-label (FL) object is referred to enable 427 identifier (ID) and locator (LID) namespaces to be split in ICN. 428 Generally, IDs are managed by applications, while locators are 429 managed by a network administrator, so that IDs are mapping to 430 heterogeneous name schemes and LIDs are mapping to network domains 431 or specific network elements. Thus the proposed FL object acts as a 432 locator (LID) and provides the flexibility to forward Interest 433 messages through mapping service between IDs and LIDs. Therefore, 434 the mapping service in control plane infrastructure can be 435 considered as NRS in this draft. 437 In MobilityFirst [9], both consumer and publisher mobility can be 438 primarily handled by the global name resolution service (GNRS) which 439 resolves GUIDs to network addresses. Thus, the GNRS must be updated 440 for mobility support when a network attached object changes its 441 point of attachment, which differs from NDN/CCN. 443 4.3.3. Scalable Routing support 445 In ICN, application names identifying contents are used directly for 446 packet delivery, so ICN routers run a name-based routing protocol to 447 build name-based routing and forwarding tables. As same as 448 scalability of IP routing, if non-aggregated name prefixes are 449 injected to the Default Route Free Zone (DFZ) of ICN, then they 450 would be driving the growth of the DFZ routing table size. Thus a 451 solution to keep the routing table size under control is needed, 452 which can be done by defining indirection layer. 454 In [38], a well-known concept of Map-and-Encap is applied to provide 455 a simple and secure namespace mapping solution to address the 456 routing scalability problem in NDN's DFZ. In the proposed map-and- 457 encap design, data whose name prefixes do not exist in the DFZ 458 forwarding table can be retrieved by a distributed mapping system 459 called NDNS, which maintains and lookups the mapping information 460 from a name to its globally routed prefixes. Therefore, NDNS is a 461 kind of NRS. 463 4.3.4. Nameless object support 465 In CCNx 1.0, the concept of "Nameless Objects" that are a Content 466 Object without a Name is introduced to provide a means to move 467 Content between storage replicas without having to rename or re-sign 468 the content objects for the new name. Nameless Objects can be 469 addressed by the ContentObjectHash that is to restrict Content 470 Object matching by using SHA-256 hash [39]. 472 An Interest message would still carry a Name and a 473 ContentObjectHash, where a Name is used for routing, while a 474 ContentObjectHash is used for matching. However, on the reverse 475 path, if the Content Object's name is missing, it is a "Nameless 476 Object" and only matches against the ContentObjectHash. Therefore, a 477 consumer needs to resolve proper name and hashes through an outside 478 system, which can be considered as NRS. 480 5. Requirements for NRS in ICN 482 In this section, we provide the requirements for designing NRS in 483 ICN in terms of service, system and security aspects, respectively. 485 5.1. Service aspect 487 We enumerate the requirements on service aspect. 489 5.1.1. Delay sensitivity 491 The name resolution process provided by the NRS must not introduce 492 significant latencies. With more number of name record replications, 493 the number of nodes involved in the name resolution may be reduced. 494 For example, in the standalone name resolution approach, with the 495 name record being replicated to higher hierarchy or the peer NRS 496 server in the overlay, the name resolution can be responded more 497 promptly. In the name based routing approach, with the content based 498 routing table being broadcast within the larger scope in the 499 network, the name resolution and request routing can have higher 500 probability to successfully reach the nearer copy of the requested 501 content. 503 The NRS deployment should balance the number of nodes involved in 504 the name resolution and the overhead/cost for the name record 505 replication. To ensure the low latency, the NRS should be able to 506 route a content request to the closest copy. Message forwarding and 507 processing should be efficient and computation complexity should be 508 reasonable low and affordable by the current processor technologies. 510 5.1.2. Time transiency 512 The NRS should support time-transient content, which is frequently 513 created in and disappearing from the network. This kind of content 514 only stays in the network for a short time, which requires the NRS 515 to be able to promptly reflect the records of them in the system. 516 For example, some video clip only exists in the network for a very 517 short time, which requires the NRS to promptly update their name 518 records. 520 5.1.3. Resolution guarantee 522 The NRS must ensure the name resolution success if the matching 523 content exists in the network, regardless of its popularity, number 524 of cached copies. 526 5.1.4. Accuracy 528 The NRS must provide accurate and up-to-date information on how to 529 reach the producer(s) of requested content with minimum overhead in 530 propagating the update information. Content mobility and expiration 531 must be reflected in the corresponding records in the NRS system 532 with minimum delay to guarantee the accurate resolution. 534 For example, a content can be moved from one domain to another 535 domain due to the mobility of the producer, then the old name record 536 should be deleted from the NRS system and a new name record should 537 be added and updated with minimum delay. 539 5.2. System aspects 541 We enumerate the requirements on system aspect. 543 5.2.1. Scalability 545 The NRS system must to be extremely scalable to support a large 546 number of content objects as well as billions of users, who may 547 access the system through various connection methods and devices. 549 Especially in IoT applications, the data size is small but 550 frequently generated by sensors. Message forwarding and processing, 551 routing table building-up and name records propagation must be 552 efficient and scalable. The memory requirement for NRS nodes should 553 be achievable by the current memory technologies. 555 5.2.2. Fault tolerance 557 The NRS must ensure resilience to node failures. After a NRS node 558 fails, the NRS system must be able to restore the name records 559 stored in the NRS node. The NRS must also ensure resolution failure 560 at one NRS node would be resolved and corrected by other NRS nodes. 562 For example, in the standalone name resolution approach, when a NRS 563 overlay server fails, the name records should be able to transferred 564 and recovered in its peer server or its replacement. In the name 565 based approach, the failure of one ICN router does not cause much 566 trouble in the name resolution, because the other alternative paths 567 can be established that bypass the failed ICN router. However, it 568 requires that the ICN router has propagated its name based routing 569 information in the network. 571 5.2.3. Minimum inter-domain traffic 573 The NRS must attempt to minimize total traffic, and inter-domain 574 traffic in particular. In order to achieve that, message propagation 575 for name resolution and retrieval should retain the locality and 576 should be kept in the network domain if that domain contains both 577 the client and the content copy. 579 For example, a client is requesting the temperature data of the 580 building that he/she is residing in, the NRS should be able to 581 return or route to the nearest gateway in the building that stores 582 such data instead of a remote server in the cloud. 584 5.2.4. Manageability 586 NRS has to be manageable since some parts of the system may grow or 587 shrink dynamically and a name resolution server may be added or 588 deleted. 590 5.2.5. Deployability 592 Deployability is important for a real world system. If the NRS can 593 be deployed from the edges, then the deployment can be simplified. 595 5.2.6. Interoperability 597 Considering the emergence of IoT applications, many standard bodies 598 for IoT have settled their ways for resource/data management. For 599 example: 601 - oneM2M[19] uses tree structure to store resources. Each resource 602 is addressable by its URI. oneM2M resources are linked together by 603 parent-child relationship or link relationship with pointers. 604 Resource resolution is indicated in the hierarchical name of the 605 resources. With one entrance, a client can go anywhere within the 606 tree structure. As an example, a content is stored under the 607 container with URI prefix of /CSEBase-ID/AE-ID/container 608 ID/contentInstance-ID. From the URI of the content, a client would 609 be able to easily do the name resolution and go to the oneM2M server 610 identified by CSEBase-ID. 612 - IETF CoRE[21] specifies the Resource Directory (RD) [23] for 613 resource registration and resolution. A RD is a database that stores 614 links about resources hosted by endpoints (EP), which are called RD 615 entries. An EP is a server that is associated with a scheme (e.g. 616 CoAP[22] by default, or HTTP), IP address and port. 618 It is likely that a physical IoT node may host one or more Eps. The 619 RD provides a set of RESTful interface for EPs to register and 620 maintain sets of RD entries, and for clients to look up resources. 622 In order for the ICN infrastructure to support IoT applications, the 623 NRS should provide the interoperability between those existing 624 resource registries as well as integration of them into the ICN 625 infrastructure. The NRS should allow different providers to coexist 626 and for requesters to choose one or more preferred providers on 627 their own. 629 5.3. Security aspect 631 We enumerate the requirements on service aspect for both the node 632 and data. 634 5.3.1. Accessibility 636 The NRS system must be prevented from the malicious users attempting 637 to hijack or corrupt name records. 639 The name records must have proper access rights such that the 640 information contained in the name record would not be revealed to 641 unauthorized users. 643 The name records may be associated within certain domain, and cannot 644 be propagated outside the domain. For example, for content that is 645 only shared within the community should be restricted within the 646 community network, outside of which the content may not exist. 648 5.3.2. Authentication 650 Users/nodes that register themselves with NRS server require the 651 authentication to ensure who claims to be. For example, the attacker 652 can act as a fake NRS server which causes disruption or intercepts 653 the data. 655 [TBD] 657 5.3.3. Data confidentiality 659 NRS has to keep the data confidentiality to prevent a lot of 660 sensitive data from reaching unauthorized data requestor in IoT 661 environment. 663 [TBD] 665 5.3.4. Privacy 667 When a private data is registered in the system, NRS has to support 668 the privacy to avoid the information leaking. Otherwise, 669 unauthorized entity may disclose the privacy. 671 [TBD] 673 6. Security Considerations 675 [TBD] 677 7. IANA Considerations 679 This document makes no specific request of IANA. 681 8. References 683 8.1. Normative References 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, DOI 687 10.17487/RFC2119, March 1997, . 690 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 691 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 692 "Information-Centric Networking (ICN) Research 693 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 694 . 696 8.2. Informative References 698 [1] G. Xylomenos, C. N. Ververidis, V. A. Siris, N. Fotiou, 699 C.Tsilopoulos, X. Vasilakos, K. V. Katsaros, and G. C. 700 Polyzos, A Survey of Information-Centric Networking Research, 701 Communications Surveys and Tutorials, Vol. 16, No. 2, 2014, 702 pp. 1024-1049. 704 [2] E. Baccelli, C. Mehlis, O. Hahm, T. Schmidt, and M. Wahlisch, 705 Information Centric Networking in the IoT: Experiments with 706 NDN in the Wild, in ACM ICN, 2014. 708 [3] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, Named data 709 networking for IoT: An architectural perspective, in European 710 Conference on Networks and Communications (EuCNC), 2014. 712 [4] T. Koponen, M. Chawla, B. Chun, A. Ermolinskiy, K. H. Kim, 713 S.Shenker, and I. Stoica, "A Data-Oriented (and Beyond) 714 Network Architecture." in ACM SIGCOMM, 2007, pp. 181-192. 716 [5] FP7 PURSUIT project. http://www.fp7-pursuit.eu/PursuitWeb/. 718 [6] FP7 SAIL project. http://www.sail-project.eu/. 720 [7] NSF Named Data Networking project. http://www.named-data.net/. 722 [8] Content Centric Networking project. http://www.ccnx.org/. 724 [9] NSF Mobility First project. 725 http://mobilityfirst.winlab.rutgers.edu/. 727 [10] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N.H. 728 Briggs, and R. L. Braynard, "Networking Named Content." in ACM 729 CoNEXT, 2009. 731 [11] A. Baid, T.Vu, and D. Raychaudhuri, "Comparing Alternative 732 Approaches for Networking of Named Objects in the Future 733 Internet." in IEEE Workshop on Emerging Design Choices in 734 Name-Oriented Networking (NOMEN), 2012. 736 [12] M. F. Bari, S. R. Chowdhury, R. Ahmed, R. Boutaba and B. 737 Mathieu, "A Survey of Naming and Routing in Information- 738 Centric Networks.", IEEE Communications Magazine, Vol. 50, 739 No.12, P. 44-53. 741 [13] J. Rajahalme, M. Sarela, K. Visala, and J. Riihijarvi, "On 742 Name-based Inter-domain Routing," Computer Networks, vol. 55, 743 no. 4, pp. 975-986, March 2011. 745 [14] K. V. Katsaros, N. Fotiou, X. Vasilakos, C. N. Ververidis, 746 C.Tsilopoulos, G. Xylomenos, and G. C. Polyzos, "On Inter- 747 Domain Name Resolution for Information-Centric Networks," in 748 Proc.IFIP-TC6 Networking Conference,2012. 750 [15] Namespace Resolution in Future Internet Architectures, draft- 751 wang-fia-namespace-01. 753 [16] PID: A Generic Naming Schema for Information-centric Network, 754 draft-zhang-icnrg-pid-naming-scheme-03. 756 [17] D. Zhang, H. Liu, Routing and Name Resolution in Information- 757 Centric Networks, 22nd International Conference on Computer 758 Communications and Networks (ICCCN), 2013. 760 [18] S. Sevilla, P. Mahadevan, J. Garcia-Luna-Aceves, "iDNS: 761 Enabling Information Centric Networking Through The DNS." Name 762 Oriented Mobility (workshop co-located with Infocom 2014). 764 [19] On the Naming and Binding of Network Destinations, 765 https://tools.ietf.org/html/rfc1498. 767 [20] oneM2M Functional Architecture TS 0001, 768 http://www.onem2m.org/technical/published-documents. 770 [21] Constrained RESTful Environments, CoRE, 771 https://datatracker.ietf.org/wg/core/charter/, 2013. 773 [22] RFC 7252, The Constrained Application Protocol (CoAP). 775 [23] CoRE Resource Directory, 776 https://datatracker.ietf.org/doc/draft-ietf-core-resource- 777 directory/. 779 [24] C. Westphal, E. Demirors, An IP-based Manifest Architecture 780 for ICN, 2nd ACM Conference on Information-Centric Networking 781 (ICN 2015). 783 [25] M. Mosko, G. Scott , I. Solis , C. Wood, CCNx Manifest 784 Specification, http://www.ccnx.org/pubs/draft-wood-icnrg- 785 ccnxmanifests-00.html. 787 [26] The Locator/ID Separation Protocol (LISP), 788 https://datatracker.ietf.org/doc/rfc6830/. 790 [27] Locator/ID Separation Protocol (LISP) Map-Server Interface, 791 https://datatracker.ietf.org/doc/rfc6833/. 793 [28] Ahlgren, B. et al., "A Survey of Information-Centric 794 Networking", IEEE Communications Magazine vol. 50, no. 7, July 795 2012. 797 [29] Xylomenos, G. et al., "A Survey of Information-Centric 798 Networking Research", IEEE Communications Surveys and 799 Tutorials vol. 16, no. 2, 2014. 801 [30] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 802 Wahlisch, "Information Centric Networking in the IoT: 803 Experiments with NDN in the Wild", ACM ICN, September 2014. 805 [31] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named 806 data networking for IoT: An architectural perspective", 807 European Conference on Networks and Communications, July 2014. 809 [32] Quevedo, J., Corujo, D., and R. Aguiar, "A case for ICN usage 810 in IoT environments", IEEE GLOBECOM, 2014. 812 [33] Amadeo, M. et al., "Information-centric networking for the 813 internet of things: challenges and opportunities", IEEE 814 Network vol. 30, no. 2, July 2016. 816 [34] Zhang, Y. et al., " Design Considerations for Applying ICN to 817 IoT", Internet Draft, draft-zhang-icnrg-icniot-00, March 2017. 819 [35] Jung, H. et al., "IDNet: Beyond All-IP Network", ETRI Jouranl 820 vol. 37, no. 5, October 2015. 822 [36] Yu Zhang et al., "A Survey of Mobility Support in Named Data 823 Networking," NOM 2016. 825 [37] R. Ravindran et al., "Forwarding-Label support in CCN 826 Protocol," IETF draft, March 2016. 828 [38] Alexander Afanasyev et al., "SNAMP: Secure Namespace Mapping 829 to Scale NDN Forwarding," IEEE Global Internet Symposium, 830 April 2015. 832 [39] Marc Mosko, "Nameless Objects," July 2015. 834 Authors' Addresses 836 Jungha Hong 837 ETRI 838 218 Gajeong-ro, Yuseung-Gu 839 Daejeon 34129 840 Korea 842 Phone: +82-42-860-0926 843 Email: jhong@etri.re.kr 845 Lijun Dong 846 Huawei Technologies 847 10180 Telesis Court 848 Suite 220 849 San Diego, CA, 92121 851 Phone: 852 Email: lijun.dong@huawei.com 854 Tae-Wan You 855 ETRI 856 218 Gajeong-ro, Yuseung-Gu 857 Daejeon 34129 858 Korea 860 Phone: +82-42-860-0642 861 Email: twyou@etri.re.kr 863 Cedric Westphal 864 Huawei Technologies 865 2330 Central Expressway 866 Santa Clara, CA 95050 868 Phone: 869 Email: cedric.westphal@huawei.com 871 Yong-Geun Hong 872 ETRI 873 218 Gajeong-ro, Yuseung-Gu 874 Daejeon 34129 875 Korea 877 Phone: +82-42-860-6557 878 Email: yghong@etri.re.kr 879 GQ Wang 880 Huawei Technologies 881 2330 Central Expressway 882 Santa Clara, CA 95050 884 Phone: 885 Email: gq.wang@huawei.com 887 Jianping Wang 888 City University Hong Kong 890 Phone: 891 Email: jianwang@cityu.edu.hk