idnits 2.17.1 draft-dong-icnrg-nrs-requirement-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 18, 2016) is 2832 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '20' is defined on line 527, 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) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Lijun Dong 2 Internet Draft Cedric Westphal 3 Intended status: Informational GQ Wang 4 Expires: January 17, 2017 Huawei Technologies 5 Jianping Wang 6 City University Hong Kong 7 July 18, 2016 9 Requirements of Name Resolution Service in ICN 10 draft-dong-icnrg-nrs-requirement-00 12 Abstract 14 This document summarizes the existing approaches for name resolution 15 in various ICN architectures, and categorizes them into two groups: 16 (1) standalone name resolution; (2) name based routing. It compares 17 the two types of approaches from the aspects of update message 18 overhead, resolution capability, node failure impact, and maintained 19 database. And hybrid approaches also exist with a subnet of routers 20 carrying out name based routing. Despite the coexistence of 21 different name resolution approaches, the Name Resolution Service 22 (NRS) is most essential service that shall be provided by the ICN 23 infrastructure. The document gives the definition of NRS in ICN and 24 proposes some requirements of NRS, i.e. resolution guarantee, delay 25 sensitivity, minimum inter-domain traffic, failure resilience, 26 accuracy, security and accessibility, scalability, and time 27 transiency, support for manifest, interoperability, resolution 28 result selection, heterogeneity, unspecified Content Name. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet-Drafts as 43 reference material or to cite them other than as "work in progress." 44 This document expires on January 17, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction...................................................2 64 1.1. Comparisons of Standalone Name Resolution and Name based 65 Routing Approaches.............................................4 66 2. Definition of Name Resolution Service in ICN...................5 67 3. Requirements of Name Resolution Service in ICN.................6 68 3.1. Resolution Guarantee......................................6 69 3.2. Delay Sensitivity.........................................6 70 3.3. Minimum Inter-Domain Traffic..............................6 71 3.4. Failure Resilience........................................6 72 3.5. Accuracy..................................................7 73 3.6. Security and accessibility................................7 74 3.7. Scalability...............................................7 75 3.8. Time Transiency...........................................8 76 3.9. Support for manifest......................................8 77 3.10. Interoperability.........................................8 78 3.11. Resolution Result Selection..............................9 79 3.12. Heterogeneity............................................9 80 3.13. Unspecified Content Name................................10 81 4. IANA Considerations...........................................10 82 5. Conclusions...................................................10 83 6. Informative References........................................10 85 1. Introduction 87 Information Centric Networking (ICN)[1] has been identified and 88 acknowledged as the most promising architecture for the future 89 Internet as well as the future Internet of Things(IoT)[2][3]. There 90 are existing efforts in designing the ICN architecture, such as 91 DONA[4], PURSUIT[5], NDN[7][10], CCN[8], SAIL[6], MobilityFirst[9]. 92 Most ICN architectures are centered around routing for content 93 retrieval. 95 ICN routing generally involves three steps: 97 - Name resolution[11][12][14][15][17][18]: matches/translates a 98 content name to locators of providers/sources that can provide the 99 content. 101 - Content request routing: routes the content request towards the 102 producer either based on the name or the locator. The process of 103 name resolution and content request routing can be integrated. If 104 integrated, the content request is routed by name, such as in 105 NDN/CCN. If not integrated, the content request is routed by the 106 locator obtained from the previous name resolution step, such as 107 in DONA, PURSUIT, SAIL, MobilityFirst. 109 - Content delivery: Constructs a path for transferring the content 110 from the provider to the requester. In the integrated approach, 111 content can be routed using breadcrumbs left by the request to 112 define a reverse path, or by some other mechanism, such as 113 including a locator for the requester in the content request. In 114 the uncombined approach, the content can be routed from the 115 provider back to the request through an independent path. 117 Thus the name resolution process in ICN architectures either can be 118 separated from the message routing (e.g. routing of content request 119 message) as a standalone process or can be integrated with the 120 message routing as one combined process. The former is referred as 121 standalone name resolution approach, the latter is referred as name 122 based routing approach in this document. 124 In the case that the content request also specifies the reverse 125 path, as in NDN/CCN, the name resolution mechanism also determines 126 the routing path for the data. This adds a requirement on the name 127 resolution service to propagate interest in a way that is consistent 128 with the subsequent data forwarding. Namely, the interest must 129 select a path for the data based upon the finding the copy of the 130 content, but also properly delivering the data. 132 A hybrid approach would combine name resolution as a subset of 133 routers on the path with some tunneling in between (say, across an 134 administrative domain) so that only a few of the nodes in the 135 architecture perform name resolution in the name-based approach. 137 Additionally, some other intermediary step may be included in the 138 name resolution, namely the mapping of one name to other names, in 139 order to facilitate the retrieval of named content, by way of a 140 manifest[24][25]. The manifest is resolved using one of the two 141 above approaches, and it may include further mapping of names to 142 content and location. The steps for name resolution then become: 143 first translate the manifest name into a location of a copy of the 144 manifest; the manifest includes further names of the content 145 components, and potentially locations for the content. The content 146 is then retrieved by using these names and/or location, potentially 147 resulting in additional name resolutions. 149 1.1. Comparison of Standalone Name Resolution and Name based Routing 150 Approaches 152 The following compares the standalone name resolution and name based 153 routing approaches from different aspects: 155 - Update message overhead: The update message overhead is due to the 156 change of content reachability, which may include content caching 157 or expiration, content producer mobility etc. The name based 158 routing approach may require to flood part of the network for 159 update propagation. In the worst case, the name based routing 160 approach may flood the whole network (but mitigating techniques 161 may be used to scope the flooding). The standalone name resolution 162 approach only requires to update propagation in part of the name 163 resolution overlay. 165 - Resolution capability: The standalone name resolution approach 166 can guarantee the resolution of any content in the network if it 167 is registered to the name resolution overlay (assuming the content 168 is being broadcast in the overlay after it is registered). On the 169 other hand, the name based routing approach can only promise a 170 high probability of content resolution, depending on the flooding 171 scope of the content availability information (i.e. content 172 publishing message and name based routing table). 174 - Node failure impact: Nodes involved in the standalone name 175 resolution approach are the name resolution overlay servers (e.g. 176 Resolution Handlers in DONA), while the nodes involved in the name 177 based routing approach are routers which route messages based on 178 locally maintained name based routing tables (e.g. NDN routers). 179 Node failures in the standalone name resolution approach may cause 180 some content resolution to fail even though the content is 181 available. This problem does not exist in the name based routing 182 approach because other alternative paths can be discovered to 183 bypass the failed ICN routers, given the assumption that the 184 network is still connected. 186 - Maintained databases: The storage usage for the standalone name 187 resolution approach is different from that of the name based 188 routing approach. The standalone name resolution approach 189 typically needs to maintain two databases: name to locator mapping 190 in the name resolution overlay and routing tables in the routers 191 on the data forwarding plane. The name based routing approach 192 needs to maintain different databases: name routing table and 193 optionally breadcrumbs for reverse routing of content back to the 194 requester. 196 2. Definition of Name Resolution Service in ICN 198 In ICN design, a name is used to identify an entity, such as named 199 data content, a device, an application, a service. ICN requires 200 uniqueness and persistency of the name of any entity to ensure the 201 reachability of the entity within certain scope and with proper 202 authentication and trust guarantees. The name does not change with 203 the mobility and multi-home of the corresponding entity. A client 204 can always use this name to retrieve the content from network and 205 verify the binding of the content and the name. Ideally, a name can 206 include any form of identifier, which can be flat, hierarchical, and 207 human readable or non-readable. 209 The Name Resolution Service (NRS) is defined as the service that is 210 provided by ICN infrastructure to help a client to reach a specific 211 piece of content, service, or host using a persistent name. The NRS 212 could take the standalone name resolution approach to return the 213 client with the locators of the content, which will be used by the 214 underlying network as the identifier to route the client's request 215 to one of the producers. The examples are iDNS [18], Global Name 216 Resolution Service (GNRS)[9], and Locator/ID Separation Protocol 217 (LISP)[26][27]based approach. The NRS could take the name based 218 routing approach, which integrates the name resolution with the 219 content request message routing. No matter which approach is taken 220 by the NRS in ICN, it is the most essential component or service of 221 the ICN infrastructure. The NRS could also take hybrid approach 222 which can perform name based routing approach from the beginning, 223 when it fails at certain router, the router can go back to the 224 standalone name resolution approach. The alternative hybrid NRS 225 approach also works, which can perform standalone name resolution 226 approach to find locators of routers which can carry out the name 227 based routing of the client's request. 229 3. Requirements of Name Resolution Service in ICN 231 3.1. Resolution Guarantee 233 The NRS must ensure the name resolution success if the matching 234 content exists in the network, regardless of its popularity, number 235 of cached copies. 237 3.2. Delay Sensitivity 239 The name resolution process provided by the NRS must not introduce 240 significant latencies. With more number of name record replications, 241 the number of nodes involved in the name resolution may be reduced. 242 For example, in the standalone name resolution approach, with the 243 name record being replicated to higher hierarchy or the peer NRS 244 server in the overlay, the name resolution can be responded more 245 promptly. In the content based routing approach, with the content 246 based routing table being broadcast within the larger scope in the 247 network, the name resolution and request routing can have higher 248 probability to successfully reach the nearer copy of the requested 249 content. 251 The NRS deployment should balance the number of nodes involved in 252 the name resolution and the overhead/cost for the name record 253 replication. To ensure the low latency, the NRS should be able to 254 route a content request to the closest copy. Message forwarding and 255 processing should be efficient and computation complexity should be 256 reasonable low and affordable by the current processor technologies. 258 3.3. Minimum Inter-Domain Traffic 260 The NRS must attempt to minimize total traffic, and inter-domain 261 traffic in particular. In order to achieve that, message propagation 262 for name resolution and retrieval should retain the locality and 263 should be kept in the network domain if that domain contains both 264 the client and the content copy. 266 For example, a client is requesting the temperature data of the 267 building that he/she is residing in, the NRS should be able to 268 return or route to the nearest gateway in the building that stores 269 such data instead of a remote server in the cloud. 271 3.4. Failure Resilience 273 The NRS must ensure resilience to node failures. After a NRS node 274 fails, the NRS system must be able to restore the name records 275 stored in the NRS node. The NRS must also ensure resolution failure 276 at one NRS node would be resolved and corrected by other NRS nodes. 278 For example, in the standalone name resolution approach, when a NRS 279 overlay server fails, the name records should be able to transferred 280 and recovered in its peer server or its replacement. In the content 281 based approach, the failure of one ICN router does not cause much 282 trouble in the name resolution, because the other alternative paths 283 can be established that bypass the failed ICN router. However, it 284 requires that the ICN router has propagated its content based 285 routing information in the network. 287 3.5. Accuracy 289 The NRS must provide accurate and up-to-date information on how to 290 reach the producer(s) of requested content with minimum overhead in 291 propagation the update information. Content mobility and expiration 292 must be reflected in the corresponding records in the NRS system 293 with minimum delay to guarantee the accurate resolution. 295 For example, a content can be moved from one domain to another 296 domain due to the mobility of the producer, then the old name record 297 should be deleted from the NRS system and a new name record should 298 be added and updated with minimum delay. 300 3.6. Security and accessibility 302 The NRS system must be prevented from the malicious users attempting 303 to hijack or corrupt name records. 305 The name records must have proper access rights such that the 306 information contained in the name record would not be revealed to 307 unauthorized users. 309 The name records may be associated within certain domain, and cannot 310 be propagated outside the domain. For example, for content that is 311 only shared within the community should be restricted within the 312 community network, outside of which the content does not exist. 314 3.7. Scalability 316 The NRS system must to be extremely scalable to support a large 317 number of content objects as well as billions of users, who may 318 access the system through various connection methods and devices. 319 Specially in IoT applications, the data size is small but frequently 320 generated by sensors. 322 Message forwarding and processing, routing table building-up and 323 name records propagation must be efficient and scalable. The memory 324 requirement for NRS nodes should be achievable by the current memory 325 technologies. 327 3.8. Time Transiency 329 The NRS should support time-transient content, which is frequently 330 created in and disappearing from the network. This kind of content 331 only stays in the network for a short time, which requires the NRS 332 be able to promptly reflects the records of them in the system. For 333 example, some video clip only exists in the network for a very short 334 time, which requires the NRS to promptly update their name records. 336 3.9. Support for manifest 338 The NRS should support resolution using manifests. Namely, if a 339 content object is described by a manifest, the NRS should support 340 efficient recursive resolution of the names included in the 341 manifest. Alternatively, if the manifest contains mapping of content 342 names to location (for instance, DASH manifest contain additional 343 Base URL for a specific content stream), then this should be 344 consistent with the mapping obtained from the NRS. 346 3.10. Interoperability 348 Considering the emergence of IoT applications, many standard bodies 349 for IoT have settled their ways for resource/data management. For 350 example: 352 - oneM2M[19] uses tree structure to store resources. Each resource 353 is addressable by its URI. oneM2M resources are linked together by 354 parent-child relationship or link relationship with pointers. 355 Resource resolution is indicated in the hierarchical name of the 356 resources. With one entrance, a client can go anywhere within the 357 tree structure. As an example, a content is stored under the 358 container with URI prefix of /CSEBase-ID/AE-ID/container- 359 ID/contentInstance-ID. From the URI of the content, a client would 360 be able to easily do the name resolution and go to the oneM2M 361 server identified by CSEBase-ID. 363 - IETF CoRE[21] specifies the Resource Directory (RD) [23] for 364 resource registration and resolution. A RD is a database that 365 stores links about resources hosted by endpoints (EP), which are 366 called RD entries. An EP is a server that is associated with a 367 scheme (e.g. CoAP[22] by default, or HTTP), IP address and port. 368 It is likely that a physical IoT node may host one or more EPs. 370 The RD provides a set of RESTful interface for EPs to register and 371 maintain sets of RD entries, and for clients to look up resources. 373 In order for the ICN infrastructure to support IoT applications, the 374 NRS should provide the interoperability between those existing 375 resource registries as well as integration of them into the ICN 376 infrastructure. The NRS should allow different providers to coexist 377 and for requesters to choose one or more preferred providers on 378 their own. 380 3.11. Resolution Result Selection 382 The NRS may be able to return some of the active producers or all of 383 them for the client's selection or select the best producer based on 384 the client's criteria and context information, e.g. producer with 385 least load, with least response time, etc. 387 3.12. Heterogeneity 389 There are heterogeneous content naming schemes[16][19] and name 390 resolution approaches from different ICN architectures. For example: 392 - Names in DONA[1] consist of the cryptographic hash of the 393 principal's public key P and a label L uniquely identifying the 394 information with respect to the principal. Name resolution in DONA 395 is provided by specialized servers called Resolution Handlers 396 (RHs). 398 - Content in PURSUIT[5] is identified by a combination of a scope ID 399 and a rendezvous ID. The scope ID represents the boundaries of a 400 defined dissemination strategy for the content it contain. The 401 rendezvous ID is the actual identity for a particular content. 402 Name resolution in PURSUIT is handled by a collection of 403 Rendezvous Nodes (RNs), which are implemented as a hierarchical 404 Dynamic Hash Table (DHT)[13][14]. 406 - Names in NDN/CCN[8][10] are hierarchical and may be similar to 407 URLs. Each name component can be anything, including a dotted 408 human-readable string or a hash value. NDN/CCN adopts the name 409 based routing. The NDN router forwards the interest by doing the 410 longest-match lookup in the Forwarding Information Base (FIB) 411 based on the content name and the interest is stored in the 412 Pending Interest Table (PIT). 414 - In MobilityFirst[9], every network entity, content has a Global 415 Unique Identifier (GUID). GUIDs are flat 160-bit strings with no 416 semantic structure. Name Resolution in MobilityFirst all is 417 carried out via a Global Name Resolution Service (GNRS). 419 Although the existing naming schemes are different, they all need to 420 provide basic functions for identifying a content, supporting trust 421 provenance, content lookup and routing. The NRS may combine the 422 advantages of different mechanisms. The NRS may be able to provide a 423 generic naming schema to resolve any type of content name, either it 424 is flat or hierarchical. 426 3.13. Unspecified Content Name 428 Currently, both the standalone name resolution and name based 429 routing approaches assume that the content name is known and 430 specified by the client, which is sometimes not the case. A client 431 may not know the exact name of the data that he/she is requesting, 432 for example, a client wants to retrieve the temperature data on 433 07/21/2015 in San Diego. In this case, the client is only able to 434 specify some semantics and contextual information of the data that 435 he/she is looking for. 437 The NRS may be able to resolve those requests by having a northbound 438 interface to the other services, which can return the content 439 name(s) matching the client's request. 441 4. IANA Considerations 443 This document makes no specific request of IANA. 445 5. Conclusions 447 In this draft, we broaden the definition of NRS in the ICN 448 infrastructure as the service which can help a client to reach a 449 producer of the requested content. Thus the NRS could take the 450 approaches of standalone name resolution, name based routing or 451 hybrid of the two. With the essence of NRS, it is urgent to identify 452 the requirements for the NRS design in ICN. In the draft, we propose 453 the NRS requirements from the different aspects and elaborate each 454 of them with examples for verification of its importance. 456 6. Informative References 458 [1] G. Xylomenos, C. N. Ververidis, V. A. Siris, N. Fotiou, C. 459 Tsilopoulos, X. Vasilakos, K. V. Katsaros, and G. C. Polyzos, 460 A Survey of Information-Centric Networking Research, 461 Communications Surveys and Tutorials, Vol. 16, No. 2, 2014, P. 462 1024-1049. 464 [2] E. Baccelli, C. Mehlis, O. Hahm, T. Schmidt, and M. Wahlisch, 465 Information Centric Networking in the IoT: Experiments with 466 NDN in the Wild, in ACM ICN, 2014. 468 [3] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, Named data 469 networking for IoT: An architectural perspective, in European 470 Conference on Networks and Communications (EuCNC), 2014. 472 [4] T. Koponen, M. Chawla, B. Chun, A. Ermolinskiy, K. H. Kim,S. 473 Shenker, and I. Stoica, "A Data-Oriented (and Beyond) Network 474 Architecture." in ACM SIGCOMM, 2007, pp. 181-192. 476 [5] FP7 PURSUIT project. http://www.fp7-pursuit.eu/PursuitWeb/. 478 [6] FP7 SAIL project. http://www.sail-project.eu/. 480 [7] NSF Named Data Networking project. http://www.named-data.net/. 482 [8] Content Centric Networking project. http://www.ccnx.org/. 484 [9] NSF Mobility First project. 485 http://mobilityfirst.winlab.rutgers.edu/. 487 [10] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. 488 H. Briggs, and R. L. Braynard, "Networking Named Content." in 489 ACM CoNEXT, 2009. 491 [11] A. Baid, T.Vu, and D. Raychaudhuri, "Comparing Alternative 492 Approaches for Networking of Named Objects in the Future 493 Internet." in IEEE Workshop on Emerging Design Choices in 494 Name-Oriented Networking (NOMEN), 2012. 496 [12] M. F. Bari, S. R. Chowdhury, R. Ahmed, R. Boutaba and B. 497 Mathieuy, "A Survey of Naming and Routing in Information- 498 Centric Networks.", IEEE Communications Magazine, Vol. 50, No. 499 12, P. 44-53. 501 [13] J. Rajahalme, M. Sarela, K. Visala, and J. Riihijarvi, "On 502 Name-based Inter-domain Routing," Computer Networks, vol. 55, 503 no. 4, pp. 975-986,March 2011. 505 [14] K. V. Katsaros, N. Fotiou, X. Vasilakos, C. N. Ververidis, C. 506 Tsilopoulos, G. Xylomenos, and G. C. Polyzos, "On Inter-Domain 507 Name Resolution for Information-Centric Networks," in Proc. 508 IFIP-TC6 Networking Conference,2012. 510 [15] Namespace Resolution in Future Internet Architectures,draft- 511 wang-fia-namespace-01. 513 [16] PID: A Generic Naming Schema for Information-centric Network, 514 draft-zhang-icnrg-pid-naming-scheme-03. 516 [17] D. Zhang, H. Liu, Routing and Name Resolution in Information- 517 Centric Networks, 22nd International Conference on Computer 518 Communications and Networks (ICCCN), 2013. 520 [18] S. Sevilla, P. Mahadevan, J. Garcia-Luna-Aceves, "iDNS: 521 Enabling Information Centric Networking Through The DNS." Name 522 Oriented Mobility (workshop co-located with Infocom 2014). 524 [19] On the Naming and Binding of Network Destinations, 525 https://tools.ietf.org/html/rfc1498. 527 [20] oneM2M Functional Architecture TS 0001, 528 http://www.onem2m.org/technical/published-documents. 530 [21] Constrained RESTful Environments, CoRE, 531 https://datatracker.ietf.org/wg/core/charter/, 2013. 533 [22] RFC 7252, The Constrained Application Protocol (CoAP). 535 [23] CoRE Resource Directory, 536 https://datatracker.ietf.org/doc/draft-ietf-core-resource- 537 directory/. 539 [24] C. Westphal, E. Demirors, An IP-based Manifest Architecture 540 for ICN, 2nd ACM Conference on Information-Centric Networking 541 (ICN 2015). 543 [25] M. Mosko , G. Scott , I. Solis , C. Wood CCNx Manifest 544 Specification, http://www.ccnx.org/pubs/draft-wood-icnrg- 545 ccnxmanifests-00.html. 547 [26] The Locator/ID Separation Protocol (LISP), 548 https://datatracker.ietf.org/doc/rfc6830/. 550 [27] Locator/ID Separation Protocol (LISP) Map-Server Interface, 551 https://datatracker.ietf.org/doc/rfc6833/. 553 Authors' Addresses 555 Lijun Dong 556 Huawei Technologies 557 10180 Telesis Court 558 Suite 220 559 San Diego, CA, 92121 561 Phone: 562 Email: lijun.dong@huawei.com 564 Cedric Westphal, GQ Wang 565 Huawei Technologies 566 2330 Central Expressway 567 Santa Clara, CA 95050 569 Phone: 570 Email: {cedric.westphal,gq.wang}@huawei.com 572 Jianping Wang 573 City University Hong Kong 575 Email: jianwang@cityu.edu.hk