idnits 2.17.1 draft-jhong-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 : ---------------------------------------------------------------------------- ** There are 27 instances of too long lines in the document, the longest one being 42 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 (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 7927' is mentioned on line 578, but not defined == Missing Reference: 'TBD' is mentioned on line 703, but not defined == Unused Reference: 'RFC7927' is defined on line 730, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 744, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 748, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 807, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 827, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 830, 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) -- No information found for draft-zhang-icnrg-icniotrequirements - is the name correct? Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 4 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: September 14, 2017 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 March 13, 2017 17 Requirements for Name Resolution Service in ICN 18 draft-jhong-icnrg-nrs-requirements-00.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 24 object names into routing hints such as locators, where names are 25 location-independent and locators are network addresses. 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 September 14, 2017. 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 ................................................ 4 62 2. Conventions and Terminology .................................. 6 63 3. Motivation .................................................. 7 64 3.1. Name Resolution Service in ICN .......................... 7 65 3.2. Handling Heterogeneous Names in ICN ..................... 8 66 3.3. Handling Dynamism in ICN ................................ 8 67 4. Requirements for NRS in ICN .................................. 9 68 4.1. Requirements on Operability ............................. 9 69 4.1.1. Scalability ........................................ 9 70 4.1.2. Delay sensitivity .................................. 9 71 4.1.3. Time transiency ................................... 10 72 4.1.4. Minimum inter-domain traffic ...................... 10 73 4.1.5. Fault tolerance ................................... 10 74 4.1.6. Resolution guarantee .............................. 10 75 4.1.7. Accuracy ......................................... 11 76 4.1.8. Heterogeneity ..................................... 11 77 4.1.9. Unspecified content name .......................... 12 78 4.2. Requirements on Manageability .......................... 12 79 4.2.1. Manageability ..................................... 12 80 4.2.2. Deployability ..................................... 12 81 4.2.3. Interoperability .................................. 12 82 4.2.4. Support for manifest .............................. 13 83 4.2.5. Resolution result selection ....................... 13 84 4.3. Requirements on Security ............................... 14 85 4.3.1. Accessibility ..................................... 14 86 4.3.2. Authentication .................................... 14 87 4.3.3. Data confidentiality .............................. 14 88 4.3.4. Privacy .......................................... 14 89 5. Use cases of NRS ........................................... 15 90 5.1. Flat Name routing support .............................. 15 91 5.2. Publisher Mobility support ............................. 15 92 5.3. Scalable Routing support ............................... 17 93 5.4. Nameless object support ................................ 17 94 6. Security Considerations ..................................... 17 95 7. IANA Considerations ........................................ 18 96 8. Conclusions ................................................ 18 97 9. References ................................................. 18 98 9.1. Normative References ................................... 18 99 9.2. Informative References ................................. 18 101 1. Introduction 103 The current Internet is a host-centric networking, where hosts are 104 uniquely identified with IP addresses and communication is possible 105 between any pair of hosts. Thus, information in the current Internet 106 is identified by the name of host where the information is stored. 107 In contrast to the host-centric networking, the primary 108 communication objects in Information-centric networking (ICN) are 109 the named data objects (NDOs) and they are uniquely identified by 110 the location-independent names. Thus, ICN aiming to the efficient 111 dissemination and retrieval of the NDOs in a global scale has been 112 identified and acknowledged as the most promising technology for the 113 future Internet architecture to overcome the limitations of the 114 current Internet such as scalability, mobility, etc.[28][29] 116 ICN also has been emerged as a candidate architecture for IoT 117 environment since IoT focuses on data and information rather than 118 end-to-end communications [30][31][32]. In addition, the following 119 ICN features are fulfilling well the architectural requirements of 120 IoT such as naming, name resolution, scalability, resource 121 constraints, mobility, caching, security, privacy, etc.[33][34]: 123 - Naming of data, devices, and services independently from their 124 locations 126 - Distributed caching and processing 128 - Decoupling between sender and receiver 130 - Mobility support 132 - Authentication and verification of content 134 Since naming data independently from the current location where it 135 is stored is a primary concept of ICN, how to discover the NDO using 136 the location-independent name is one of the most important design 137 challenges in ICN. Thus, most ICN architectures, such as DONA[4], 138 PURSUIT[5], NDN[7][10], CCN[8], SAIL[6], MobilityFirst[9] are 139 centered around routing for content retrieval. 141 ICN routing generally involves three steps: 143 - Name resolution[11][12][14][15][17][18]: matches/translates a 144 content name to locators of providers/sources that can provide the 145 content. 147 - Content request routing: routes the content request towards the 148 producer either based on the name or the locator. The process of 149 name resolution and content request routing can be integrated. If 150 integrated, the content request is routed by name, such as in 151 NDN/CCN. If not integrated, the content request is routed by the 152 locator obtained from the previous name resolution step, such as 153 in DONA, PURSUIT, SAIL, MobilityFirst. 155 - Content delivery: Constructs a path for transferring the content 156 from the provider to the requester. In the integrated approach, 157 content can be routed using breadcrumbs left by the request to 158 define a reverse path, or by some other mechanism, such as 159 including a locator for the requester in the content request. In 160 the uncombined approach, the content can be routed from the 161 provider back to the request through an independent path. 163 Thus the name resolution process in ICN architectures either can be 164 separated from the message routing (e.g. routing of content request 165 message) as a standalone process or can be integrated with the 166 message routing as one combined process. The former is referred as 167 standalone name resolution approach, the latter is referred as name 168 based routing approach in this document. 170 The following compares the standalone name resolution and name based 171 routing approaches from different aspects: 173 - Update message overhead: The update message overhead is due to the 174 change of content reachability, which may include content caching 175 or expiration, content producer mobility etc. The name based 176 routing approach may require to flood part of the network for 177 update propagation. In the worst case, the name based routing 178 approach may flood the whole network (but mitigating techniques 179 may be used to scope the flooding). The standalone name resolution 180 approach only requires to update propagation in part of the name 181 resolution overlay. 183 - Resolution capability: The standalone name resolution approach can 184 guarantee the resolution of any content in the network if it is 185 registered to the name resolution overlay (assuming the content is 186 being broadcast in the overlay after it is registered). On the 187 other hand, the name based routing approach can only promise a 188 high probability of content resolution, depending on the flooding 189 scope of the content availability information (i.e. content 190 publishing message and name based routing table). 192 - Node failure impact: Nodes involved in the standalone name 193 resolution approach are the name resolution overlay servers (e.g. 195 Resolution Handlers in DONA), while the nodes involved in the name 196 based routing approach are routers which route messages based on 197 locally maintained name based routing tables (e.g. NDN routers). 198 Node failures in the standalone name resolution approach may cause 199 some content resolution to fail even though the content is 200 available. This problem does not exist in the name based routing 201 approach because other alternative paths can be discovered to 202 bypass the failed ICN routers, given the assumption that the 203 network is still connected. 205 - Maintained databases: The storage usage for the standalone name 206 resolution approach is different from that of the name based 207 routing approach. The standalone name resolution approach 208 typically needs to maintain two databases: name to locator mapping 209 in the name resolution overlay and routing tables in the routers 210 on the data forwarding plane. The name based routing approach 211 needs to maintain different databases: name routing table and 212 optionally breadcrumbs for reverse routing of content back to the 213 requester. 215 Despite the coexistence of different name resolution approaches, the 216 Name Resolution Service (NRS) is most essential service that shall 217 be provided by the ICN infrastructure. Thus, in this document, we 218 give the definition of NRS in ICN and discuss the motivation and the 219 requirements in designing the NRS for ICN. 221 2. Conventions and Terminology 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 224 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 225 this document are to be interpreted as described in [RFC2119]. 227 3. Motivation 229 In this section, we give the definition of NRS in ICN and discuss 230 the motivation why NRS is needed in ICN. 232 3.1. Name Resolution Service in ICN 234 The Name Resolution Service (NRS) is defined as the service that is 235 provided by ICN infrastructure to help a client to reach a specific 236 piece of content, service, or host using a persistent name. 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 interest in a way that is consistent 253 with the subsequent data forwarding. Namely, the interest must 254 select a path for the data based upon the finding the copy of the 255 content, 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 No matter which approach is taken by the NRS in ICN, it is the most 284 essential component or service of the ICN infrastructure. 286 3.2. Handling Heterogeneous Names in ICN 288 In ICN design, a name is used to identify an entity, such as named 289 data content, a device, an application, a service. ICN requires 290 uniqueness and persistency of the name of any entity to ensure the 291 reachability of the entity within certain scope and with proper 292 authentication and trust guarantees. The name does not change with 293 the mobility and multi-home of the corresponding entity. A client 294 can always use this name to retrieve the content from network and 295 verify the binding of the content and the name. 297 Ideally, a name can include any form of identifier, which can be 298 flat, hierarchical, and human readable or non-readable. 300 3.3. Handling Dynamism in ICN 302 I 303 ICN has the dynamic features like mobility, multi-homing, migration, 304 and replication of named resources such as content, devices, 305 services, etc. The dynamism of the names resources will be more in 306 future networking contexts such as 5G or when services are 307 virtualized over wider geography due to the namespace expansion into 308 the routing/forwarding. 310 4. Requirements for NRS in ICN 312 In this section, we provide the requirements for designing NRS in 313 ICN in terms of operability, security and manageability, 314 respectively. 316 4.1. Requirements on Operability 318 The requirements on operability aspect are things that should be 319 considered when the key operations of NRS are designed. 321 4.1.1. Scalability 323 The NRS system must to be extremely scalable to support a large 324 number of content objects as well as billions of users, who may 325 access the system through various connection methods and devices. 326 Especially in IoT applications, the data size is small but 327 frequently generated by sensors. Message forwarding and processing, 328 routing table building-up and name records propagation must be 329 efficient and scalable. The memory requirement for NRS nodes should 330 be achievable by the current memory technologies. 332 4.1.2. Delay sensitivity 334 The name resolution process provided by the NRS must not introduce 335 significant latencies. With more number of name record replications, 336 the number of nodes involved in the name resolution may be reduced. 337 For example, in the standalone name resolution approach, with the 338 name record being replicated to higher hierarchy or the peer NRS 339 server in the overlay, the name resolution can be responded more 340 promptly. In the name based routing approach, with the content based 341 routing table being broadcast within the larger scope in the 342 network, the name resolution and request routing can have higher 343 probability to successfully reach the nearer copy of the requested 344 content. 346 The NRS deployment should balance the number of nodes involved in 347 the name resolution and the overhead/cost for the name record 348 replication. To ensure the low latency, the NRS should be able to 349 route a content request to the closest copy. Message forwarding and 350 processing should be efficient and computation complexity should be 351 reasonable low and affordable by the current processor technologies. 353 4.1.3. Time transiency 355 The NRS should support time-transient content, which is frequently 356 created in and disappearing from the network. This kind of content 357 only stays in the network for a short time, which requires the NRS 358 to be able to promptly reflect the records of them in the system. 359 For example, some video clip only exists in the network for a very 360 short time, which requires the NRS to promptly update their name 361 records. 363 4.1.4. Minimum inter-domain traffic 365 The NRS must attempt to minimize total traffic, and inter-domain 366 traffic in particular. In order to achieve that, message propagation 367 for name resolution and retrieval should retain the locality and 368 should be kept in the network domain if that domain contains both 369 the client and the content copy. 371 For example, a client is requesting the temperature data of the 372 building that he/she is residing in, the NRS should be able to 373 return or route to the nearest gateway in the building that stores 374 such data instead of a remote server in the cloud. 376 4.1.5. Fault tolerance 378 The NRS must ensure resilience to node failures. After a NRS node 379 fails, the NRS system must be able to restore the name records 380 stored in the NRS node. The NRS must also ensure resolution failure 381 at one NRS node would be resolved and corrected by other NRS nodes. 383 For example, in the standalone name resolution approach, when a NRS 384 overlay server fails, the name records should be able to transferred 385 and recovered in its peer server or its replacement. In the name 386 based approach, the failure of one ICN router does not cause much 387 trouble in the name resolution, because the other alternative paths 388 can be established that bypass the failed ICN router. However, it 389 requires that the ICN router has propagated its name based routing 390 information in the network. 392 4.1.6. Resolution guarantee 394 The NRS must ensure the name resolution success if the matching 395 content exists in the network, regardless of its popularity, number 396 of cached copies. 398 4.1.7. Accuracy 400 The NRS must provide accurate and up-to-date information on how to 401 reach the producer(s) of requested content with minimum overhead in 402 propagating the update information. Content mobility and expiration 403 must be reflected in the corresponding records in the NRS system 404 with minimum delay to guarantee the accurate resolution. 406 For example, a content can be moved from one domain to another 407 domain due to the mobility of the producer, then the old name record 408 should be deleted from the NRS system and a new name record should 409 be added and updated with minimum delay. 411 4.1.8. Heterogeneity 413 There are heterogeneous content naming schemes[16][19] and name 414 resolution approaches from different ICN architectures. For example: 416 - Names in DONA[1] consist of the cryptographic hash of the 417 principal's public key P and a label L uniquely identifying the 418 information with respect to the principal. Name resolution in DONA 419 is provided by specialized servers called Resolution Handlers (RHs). 421 - Content in PURSUIT[5] is identified by a combination of a scope ID 422 and a rendezvous ID. The scope ID represents the boundaries of a 423 defined dissemination strategy for the content it contain. The 424 rendezvous ID is the actual identity for a particular content. Name 425 resolution in PURSUIT is handled by a collection of Rendezvous Nodes 426 (RNs), which are implemented as a hierarchical Dynamic Hash Table 427 (DHT)[13][14]. 429 - Names in NDN/CCN[8][10] are hierarchical and may be similar to 430 URLs. Each name component can be anything, including a dotted human- 431 readable string or a hash value. NDN/CCN adopts the name based 432 routing. The NDN router forwards the interest by doing the longest- 433 match lookup in the Forwarding Information Base (FIB) based on the 434 content name and the interest is stored in the Pending Interest 435 Table (PIT). 437 - In MobilityFirst[9], every network entity, content has a Global 438 Unique Identifier (GUID). GUIDs are flat 160-bit strings with no 439 semantic structure. Name Resolution in MobilityFirst all is carried 440 out via a Global Name Resolution Service (GNRS). 442 Although the existing naming schemes are different, they all need to 443 provide basic functions for identifying a content, supporting trust 444 provenance, content lookup and routing. The NRS may combine the 445 advantages of different mechanisms. The NRS may be able to provide a 446 generic naming schema to resolve any type of content name, either it 447 is flat or hierarchical. 449 4.1.9. Unspecified content name 451 Currently, both the standalone name resolution and name based 452 routing approaches assume that the content name is known (or 453 potentially retrieved from some other service) and specified to the 454 network by the client, which is sometimes not the case. A client may 455 not know the exact name of the data that he/she is requesting. For 456 example, a client wants to retrieve the temperature data on 457 07/21/2015 in San Diego. In this case, the client is only able to 458 specify some semantics and contextual information of the data that 459 he/she is looking for. 461 The NRS may be able to resolve those requests by having a northbound 462 interface to the other services, which can return the content 463 name(s) matching the client's request. 465 4.2. Requirements on Manageability 467 Requirements on manageability are things that should be considered 468 in terms of the system management aspect. 470 4.2.1. Manageability 472 NRS has to be manageable since some parts of the system may grow or 473 shrink dynamically and a name resolution server may be added or 474 deleted. 476 4.2.2. Deployability 478 Deployability is important for a real world system. If the NRS can 479 be deployed from the edges, then the deployment can be simplified. 481 4.2.3. Interoperability 483 Considering the emergence of IoT applications, many standard bodies 484 for IoT have settled their ways for resource/data management. For 485 example: 487 - oneM2M[19] uses tree structure to store resources. Each resource 488 is addressable by its URI. oneM2M resources are linked together by 489 parent-child relationship or link relationship with pointers. 491 Resource resolution is indicated in the hierarchical name of the 492 resources. With one entrance, a client can go anywhere within the 493 tree structure. As an example, a content is stored under the 494 container with URI prefix of /CSEBase-ID/AE-ID/container 495 ID/contentInstance-ID. From the URI of the content, a client would 496 be able to easily do the name resolution and go to the oneM2M server 497 identified by CSEBase-ID. 499 - IETF CoRE[21] specifies the Resource Directory (RD) [23] for 500 resource registration and resolution. A RD is a database that stores 501 links about resources hosted by endpoints (EP), which are called RD 502 entries. An EP is a server that is associated with a scheme (e.g. 503 CoAP[22] by default, or HTTP), IP address and port. 505 It is likely that a physical IoT node may host one or more Eps. The 506 RD provides a set of RESTful interface for EPs to register and 507 maintain sets of RD entries, and for clients to look up resources. 509 In order for the ICN infrastructure to support IoT applications, the 510 NRS should provide the interoperability between those existing 511 resource registries as well as integration of them into the ICN 512 infrastructure. The NRS should allow different providers to coexist 513 and for requesters to choose one or more preferred providers on 514 their own. 516 4.2.4. Support for manifest 518 The NRS should support resolution using manifests. Namely, if a 519 content object is described by a manifest, the NRS should support 520 efficient recursive resolution of the names included in the 521 manifest. Alternatively, if the manifest contains mapping of content 522 names to location (for instance, DASH manifest may contain 523 additional Base URL for a specific content stream), then this should 524 be consistent with the mapping obtained from the NRS. 526 4.2.5. Resolution result selection 528 The NRS may be able to return some of the active producers or all of 529 them for the client's selection or select the best producer based on 530 the client's criteria and context information, e.g. producer with 531 least load, with least response time, etc. 533 4.3. Requirements on Security 535 Requirements on security are things that should be considered in 536 terms of the security aspect for both the node and data. 538 4.3.1. Accessibility 540 The NRS system must be prevented from the malicious users attempting 541 to hijack or corrupt name records. 543 The name records must have proper access rights such that the 544 information contained in the name record would not be revealed to 545 unauthorized users. 547 The name records may be associated within certain domain, and cannot 548 be propagated outside the domain. For example, for content that is 549 only shared within the community should be restricted within the 550 community network, outside of which the content may not exist. 552 4.3.2. Authentication 554 Users/nodes that register themselves with NRS server require the 555 authentication to ensure who claims to be. For example, the attacker 556 can act as a fake NRS server which causes disruption or intercepts 557 the data. 559 4.3.3. Data confidentiality 561 NRS has to keep the data confidentiality to prevent a lot of 562 sensitive data from reaching unauthorized data requestor in IoT 563 environment. 565 4.3.4. Privacy 567 When a private data is registered in the system, NRS has to support 568 the privacy to avoid the information leaking. Otherwise, 569 unauthorized entity may disclose the privacy. 571 5. Use cases of NRS 573 In this section, we describe usages of NRS in the ICN literature. 575 5.1. Flat Name routing support 577 In ICN, data objects must be identified by names regardless their 578 location or container [RFC 7927] and the names are divided into two 579 types of schemes: hierarchical and flat namespaces. A hierarchical 580 scheme used in CCN and NDN architectures has a structure similar to 581 current URIs, where the hierarchy improves scalability of routing 582 system. It is because the hierarchy enables aggregation of the name 583 resulting in reducing the size of RIB or FIB as similar to IP 584 routing system. 586 In a flat scheme, on the other hand, name routing is not easy since 587 names in a flat namespace cannot be aggregated anymore, which would 588 cause more the scalability problem in routing system. In order to 589 address such problem, a flat name is resolved to some information 590 which is routable through NRS or a sort of NRS in various ICN 591 literatures. 593 In PURSUIT [5], names are flat and the rendezvous functions are 594 defined for NRS, which is implemented by a set of Rendezvous Nodes 595 (RNs), the Rendezvous Network (RENE). Thus a name consisted of a 596 sequence of scope IDs and a single rendezvous ID is routed by RNs in 597 RENE. Thus, PURSUIT decouples name resolution and data routing, 598 where NRS is performed by the RENE. 600 In MobilityFirst [9], a name called a global unique Identifier 601 (GUID) derived from a human-readable name via a global naming 602 service is flat typed 160-bits strings with self-certifying 603 function. Thus, MobilityFirst defines a global name resolution 604 service (GNRS) which resolves GUIDs to network addresses and 605 decouples name resolution and data routing as similar to PURSUIT. 607 5.2. Publisher Mobility support 609 In ICN literature, it is said that mobility can be achieved in 610 fundamental feature of ICN. Especially, consumer or client mobility 611 can be achieved by allowing information requests to basic procedure 612 from different interfaces or through attachment point of the new 613 network. Moreover, seamless mobility service in ICN ensures that 614 content reception continues without any disruption in ICN 615 application, so in consumer point of view, seamless mobility can be 616 easily supported. 618 However, producer or publisher mobility in ICN is more complicated 619 to be supported. If a publisher moves into different authority 620 domain or network location, then the request for a content published 621 by the moving publisher with origin name would be hardly forwarded 622 to the moving publisher. Especially in a hierarchical name scheme, 623 publisher mobility support is much harder than in a flat name scheme 624 since the routing tables related in broad area should be updated 625 according to the publisher movement. Therefore, various ICN 626 literatures would adopt NRS to achieve the publisher mobility, where 627 NRS can be implemented in different ways such as rendezvous 628 mechanism, mapping, etc. 630 In NDN, for publisher mobility support, rendezvous mechanisms have 631 been proposed to build interests rendezvous (RV) with data generated 632 by a mobile producer (MP) [36]. There can be classified two 633 approaches such as chase mobile producer and rendezvous data. 634 Regarding MP chasing, rendezvous acts as a mapping service that 635 provides the mapping from the name of the data produced by the MP to 636 the MP's current point of attachment (PoA) name. Alternatively, the 637 RV serves as a home agent like as IP mobility support, so the RV 638 enables consumer's interest message to tunnel towards the MP at the 639 PoA. Regarding rendezvous data, moving the data produced by the MP 640 have been hosting at data depot instead of forwarding interest 641 messages. Thus a consumer's interest message can be forwarded to 642 stationary place as called data rendezvous, so it would either 643 return the data or fetch it using another mapping solution. 644 Therefore, RV or other mapping functions are in the role of NRS in 645 NDN. 647 In [37], forwarding-label (FL) object is referred to enable 648 identifier (ID) and locator (LID) namespaces to be split in ICN. 649 Generally, IDs are managed by applications, while locators are 650 managed by a network administrator, so that IDs are mapping to 651 heterogeneous name schemes and LIDs are mapping to network domains 652 or specific network elements. Thus the proposed FL object acts as a 653 locator (LID) and provides the flexibility to forward Interest 654 messages through mapping service between IDs and LIDs. Therefore, 655 the mapping service in control plane infrastructure can be 656 considered as NRS in this draft. 658 In MobilityFirst [9], both consumer and publisher mobility can be 659 primarily handled by the global name resolution service (GNRS) which 660 resolves GUIDs to network addresses. Thus, the GNRS must be updated 661 for mobility support when a network attached object changes its 662 point of attachment, which differs from NDN/CCN. 664 5.3. Scalable Routing support 666 In ICN, application names identifying contents are used directly for 667 packet delivery, so ICN routers run a name-based routing protocol to 668 build name-based routing and forwarding tables. As same as 669 scalability of IP routing, if non-aggregated name prefixes are 670 injected to the Default Route Free Zone (DFZ) of ICN, then they 671 would be driving the growth of the DFZ routing table size. Thus a 672 solution to keep the routing table size under control is needed, 673 which can be done by defining indirection layer. 675 In [38], a well-known concept of Map-and-Encap is applied to provide 676 a simple and secure namespace mapping solution to address the 677 routing scalability problem in NDN's DFZ. In the proposed map-and- 678 encap design, data whose name prefixes do not exist in the DFZ 679 forwarding table can be retrieved by a distributed mapping system 680 called NDNS, which maintains and lookups the mapping information 681 from a name to its globally routed prefixes. Therefore, NDNS is a 682 kind of NRS. 684 5.4. Nameless object support 686 In CCNx 1.0, the concept of "Nameless Objects" that are a Content 687 Object without a Name is introduced to provide a means to move 688 Content between storage replicas without having to rename or re-sign 689 the content objects for the new name. Nameless Objects can be 690 addressed by the ContentObjectHash that is to restrict Content 691 Object matching by using SHA-256 hash [39]. 693 An Interest message would still carry a Name and a 694 ContentObjectHash, where a Name is used for routing, while a 695 ContentObjectHash is used for matching. However, on the reverse 696 path, if the Content Object's name is missing, it is a "Nameless 697 Object" and only matches against the ContentObjectHash. Therefore, a 698 consumer needs to resolve proper name and hashes through an outside 699 system, which can be considered as NRS. 701 6. Security Considerations 703 [TBD] 705 7. IANA Considerations 707 This document makes no specific request of IANA. 709 8. Conclusions 711 In this draft, we broaden the definition of NRS in the ICN 712 infrastructure as the service which can help a client to reach a 713 producer of the requested content. Thus the NRS could take the 714 approaches of standalone name resolution, name based routing or 715 hybrid of the two. With the essence of NRS, it is urgent to identify 716 the requirements for the NRS design in ICN. In the draft, we propose 717 the NRS requirements from the different aspects and elaborate each 718 of them with examples for verification of its importance. We also 719 discuss the use cases of NRS in the ICN literature. 721 9. References 723 9.1. Normative References 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, DOI 727 10.17487/RFC2119, March 1997, . 730 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 731 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 732 "Information-Centric Networking (ICN) Research 733 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 734 . 736 9.2. Informative References 738 [1] G. Xylomenos, C. N. Ververidis, V. A. Siris, N. Fotiou, 739 C.Tsilopoulos, X. Vasilakos, K. V. Katsaros, and G. C. 740 Polyzos, A Survey of Information-Centric Networking Research, 741 Communications Surveys and Tutorials, Vol. 16, No. 2, 2014, 742 pp. 1024-1049. 744 [2] E. Baccelli, C. Mehlis, O. Hahm, T. Schmidt, and M. Wahlisch, 745 Information Centric Networking in the IoT: Experiments with 746 NDN in the Wild, in ACM ICN, 2014. 748 [3] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, Named data 749 networking for IoT: An architectural perspective, in European 750 Conference on Networks and Communications (EuCNC), 2014. 752 [4] T. Koponen, M. Chawla, B. Chun, A. Ermolinskiy, K. H. Kim, 753 S.Shenker, and I. Stoica, "A Data-Oriented (and Beyond) 754 Network Architecture." in ACM SIGCOMM, 2007, pp. 181-192. 756 [5] FP7 PURSUIT project. http://www.fp7-pursuit.eu/PursuitWeb/. 758 [6] FP7 SAIL project. http://www.sail-project.eu/. 760 [7] NSF Named Data Networking project. http://www.named-data.net/. 762 [8] Content Centric Networking project. http://www.ccnx.org/. 764 [9] NSF Mobility First project. 765 http://mobilityfirst.winlab.rutgers.edu/. 767 [10] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N.H. 768 Briggs, and R. L. Braynard, "Networking Named Content." in ACM 769 CoNEXT, 2009. 771 [11] A. Baid, T.Vu, and D. Raychaudhuri, "Comparing Alternative 772 Approaches for Networking of Named Objects in the Future 773 Internet." in IEEE Workshop on Emerging Design Choices in 774 Name-Oriented Networking (NOMEN), 2012. 776 [12] M. F. Bari, S. R. Chowdhury, R. Ahmed, R. Boutaba and B. 777 Mathieu, "A Survey of Naming and Routing in Information- 778 Centric Networks.", IEEE Communications Magazine, Vol. 50, 779 No.12, P. 44-53. 781 [13] J. Rajahalme, M. Sarela, K. Visala, and J. Riihijarvi, "On 782 Name-based Inter-domain Routing," Computer Networks, vol. 55, 783 no. 4, pp. 975-986, March 2011. 785 [14] K. V. Katsaros, N. Fotiou, X. Vasilakos, C. N. Ververidis, 786 C.Tsilopoulos, G. Xylomenos, and G. C. Polyzos, "On Inter- 787 Domain Name Resolution for Information-Centric Networks," in 788 Proc.IFIP-TC6 Networking Conference,2012. 790 [15] Namespace Resolution in Future Internet Architectures, draft- 791 wang-fia-namespace-01. 793 [16] PID: A Generic Naming Schema for Information-centric Network, 794 draft-zhang-icnrg-pid-naming-scheme-03. 796 [17] D. Zhang, H. Liu, Routing and Name Resolution in Information- 797 Centric Networks, 22nd International Conference on Computer 798 Communications and Networks (ICCCN), 2013. 800 [18] S. Sevilla, P. Mahadevan, J. Garcia-Luna-Aceves, "iDNS: 801 Enabling Information Centric Networking Through The DNS." Name 802 Oriented Mobility (workshop co-located with Infocom 2014). 804 [19] On the Naming and Binding of Network Destinations, 805 https://tools.ietf.org/html/rfc1498. 807 [20] oneM2M Functional Architecture TS 0001, 808 http://www.onem2m.org/technical/published-documents. 810 [21] Constrained RESTful Environments, CoRE, 811 https://datatracker.ietf.org/wg/core/charter/, 2013. 813 [22] RFC 7252, The Constrained Application Protocol (CoAP). 815 [23] CoRE Resource Directory, 816 https://datatracker.ietf.org/doc/draft-ietf-core-resource- 817 directory/. 819 [24] C. Westphal, E. Demirors, An IP-based Manifest Architecture 820 for ICN, 2nd ACM Conference on Information-Centric Networking 821 (ICN 2015). 823 [25] M. Mosko, G. Scott , I. Solis , C. Wood, CCNx Manifest 824 Specification, http://www.ccnx.org/pubs/draft-wood-icnrg- 825 ccnxmanifests-00.html. 827 [26] The Locator/ID Separation Protocol (LISP), 828 https://datatracker.ietf.org/doc/rfc6830/. 830 [27] Locator/ID Separation Protocol (LISP) Map-Server Interface, 831 https://datatracker.ietf.org/doc/rfc6833/. 833 [28] Ahlgren, B. et al., "A Survey of Information-Centric 834 Networking", IEEE Communications Magazine vol. 50, no. 7, July 835 2012. 837 [29] Xylomenos, G. et al., "A Survey of Information-Centric 838 Networking Research", IEEE Communications Surveys and 839 Tutorials vol. 16, no. 2, 2014. 841 [30] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 842 Wahlisch, "Information Centric Networking in the IoT: 843 Experiments with NDN in the Wild", ACM ICN, September 2014. 845 [31] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named 846 data networking for IoT: An architectural perspective", 847 European Conference on Networks and Communications, July 2014. 849 [32] Quevedo, J., Corujo, D., and R. Aguiar, "A case for ICN usage 850 in IoT environments", IEEE GLOBECOM, 2014. 852 [33] Amadeo, M. et al., "Information-centric networking for the 853 internet of things: challenges and opportunities", IEEE 854 Network vol. 30, no. 2, July 2016. 856 [34] Zhang, Y. et al., "Requirements and Challenges for IoT over 857 ICN", Internet Draft, draft-zhang-icnrg-icniotrequirements-01, 858 April 2016. 860 [35] Jung, H. et al., "IDNet: Beyond All-IP Network", ETRI Jouranl 861 vol. 37, no. 5, October 2015. 863 [36] Yu Zhang et al., "A Survey of Mobility Support in Named Data 864 Networking," NOM 2016. 866 [37] R. Ravindran et al., "Forwarding-Label support in CCN 867 Protocol," IETF draft, March 2016. 869 [38] Alexander Afanasyev et al., "SNAMP: Secure Namespace Mapping 870 to Scale NDN Forwarding," IEEE Global Internet Symposium, 871 April 2015. 873 [39] Marc Mosko, "Nameless Objects," July 2015. 875 Authors' Addresses 877 Jungha Hong 878 ETRI 879 218 Gajeong-ro, Yuseung-Gu 880 Daejeon 34129 881 Korea 883 Phone: +82-42-860-0926 884 Email: jhong@etri.re.kr 886 Lijun Dong 887 Huawei Technologies 888 10180 Telesis Court 889 Suite 220 890 San Diego, CA, 92121 892 Phone: 893 Email: lijun.dong@huawei.com 895 Tae-Wan You 896 ETRI 897 218 Gajeong-ro, Yuseung-Gu 898 Daejeon 34129 899 Korea 901 Phone: +82-42-860-0642 902 Email: twyou@etri.re.kr 904 Cedric Westphal 905 Huawei Technologies 906 2330 Central Expressway 907 Santa Clara, CA 95050 909 Phone: 910 Email: cedric.westphal@huawei.com 912 Yong-Geun Hong 913 ETRI 914 218 Gajeong-ro, Yuseung-Gu 915 Daejeon 34129 916 Korea 918 Phone: +82-42-860-6557 919 Email: yghong@etri.re.kr 920 GQ Wang 921 Huawei Technologies 922 2330 Central Expressway 923 Santa Clara, CA 95050 925 Phone: 926 Email: gq.wang@huawei.com 928 Jianping Wang 929 City University Hong Kong 931 Phone: 932 Email: jianwang@cityu.edu.hk