idnits 2.17.00 (12 Aug 2021) /tmp/idnits28647/draft-hong-icnrg-nrs-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 29, 2016) is 2054 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '8' on line 299 == Missing Reference: 'TBD' is mentioned on line 323, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group J. Hong 3 Internet-Draft T. You 4 Intended status: Informational Y-G. Hong 5 Expires: April 2, 2017 ETRI 6 September 29, 2016 8 Requirements for Name Resolution Service in ICN 9 draft-hong-icnrg-nrs-requirements-00 11 Abstract 13 This document discusses the motivation and requirements for Name 14 Resolution Service (NRS) in ICN. The NRS in ICN is to translate 15 object names into routing hints such as locators, where names are 16 location-independent and locators are network addresses. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 2, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 54 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Requirements for NRS in ICN . . . . . . . . . . . . . . . . . 4 56 4.1. Requirements on Operability . . . . . . . . . . . . . . . 4 57 4.1.1. Scalability . . . . . . . . . . . . . . . . . . . . . 4 58 4.1.2. Low latency . . . . . . . . . . . . . . . . . . . . . 4 59 4.1.3. Fast Update . . . . . . . . . . . . . . . . . . . . . 5 60 4.1.4. Locality . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1.5. Resilience . . . . . . . . . . . . . . . . . . . . . 5 62 4.1.6. Fault tolerance / Isolation . . . . . . . . . . . . . 5 63 4.2. Requirements on Manageability . . . . . . . . . . . . . . 5 64 4.2.1. Manageabiliyt . . . . . . . . . . . . . . . . . . . . 5 65 4.2.2. Deployability . . . . . . . . . . . . . . . . . . . . 5 66 4.2.3. Interoperability . . . . . . . . . . . . . . . . . . 6 67 4.3. Requirements on Security . . . . . . . . . . . . . . . . 6 68 4.3.1. Access control . . . . . . . . . . . . . . . . . . . 6 69 4.3.2. Authentication . . . . . . . . . . . . . . . . . . . 6 70 4.3.3. Data confidentiality . . . . . . . . . . . . . . . . 6 71 4.3.4. Data integrity . . . . . . . . . . . . . . . . . . . 6 72 4.3.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Use case of NRS . . . . . . . . . . . . . . . . . . . . . . . 6 74 5.1. Lookup by Name Routing (LBNR) . . . . . . . . . . . . . . 6 75 5.2. Route by Name Routing (RBNR) . . . . . . . . . . . . . . 7 76 5.3. Hybrid Routing (HR) . . . . . . . . . . . . . . . . . . . 7 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 82 9.2. Informative References . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 The current Internet is a host-centric networkAhlgrening, where hosts 88 are uniquely identified with IP addresses and communication is 89 possible between any pair of hosts. Thus, information in the current 90 Internet is identified by the name of host where the information is 91 stored. In contrast to the host-centric networking, the primary 92 communication objects in Information-centric networking (ICN) are the 93 named data objects (NDOs) and they are uniquely identified by the 94 location-independent names. Thus, ICN aiming to the efficient 95 dissemination and retrieval of the NDOs in a global scale has been 96 recognized as a promising technology for the future Internet 97 architecture to overcome the limitations of the current Internet such 98 as scalability, mobility, etc [Ahlgren] [Xylomenos]. 100 ICN alsoBaccelliBaccelliBaccelli has been emerged as a candidate 101 architecture for IoT environment since IoT focuses on data and 102 information rather than end-to-end communications [Baccelli] [Amadeo] 103 [Quevedo]. In addition, the following ICN features are fulfilling 104 well the architectural requirements of IoT such as naming, name 105 resolution, scalability, resource constraints, mobility, caching, 106 security, privacy, etc. [Amadeo2] [Zhang]: 108 o Naming of data, devices, and services independently from their 109 locations 111 o Distributed caching and processing 113 o Decoupling between sender and receiver 115 o Mobility support 117 o Authentication and verification of content 119 Since naming data independently from the current location where it is 120 stored is a primary concept of ICN, how to discover the NDO using the 121 location-independent name is one of the most important design 122 challenges in ICN. There are several projects for ICN which adopt 123 the lookup-by-name routing scheme exploiting the name resolution 124 service (NRS) to discover the NDO using the location-independent 125 name, where the NRS for ICN is to translate object names into routing 126 hints such as locators. Thus, in this document, we provide the 127 motivation and the requirements in designing the NRS for ICN. 129 2. Conventions and Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. Motivation 137 In this section, we provide why NRS is needed in ICN and how it will 138 fit into ICN architecture. 140 ICN routing is a process how to retrieve the NDO based on its name 141 independently from its network address and may comprise three steps: 142 name resolution, content discovery, and content delivery. Depending 143 on how these steps are combined, ICN routing schemes can be 144 categorized as Route-By-Name Routing (RBNR), Lookup-By-Name Routing 145 (LBNR), and Hybrid Routing (HR). RBNR omits the first name 146 resolution step and directly uses the name to route the request to 147 the NDO. LBNR uses the first name resolution step to translate the 148 name into its locator and the second content discovery step is based 149 on the locator. HR combines RBNR and LBNR to benefit from their 150 advantages [RFC7927]. 152 CCN [Jacobson] and NDN [Zhang2] are the instantiation of RBNR. On 153 the other hand, LBNR is used in NetInf [Dannewitz], MobilityFirst 154 [Seskar], and IDNet [Jung]. Consequently, NRS is necessary unless 155 RBNR itself is chosen as an ICN routing scheme. NRS is also required 156 in ICN for the efficient support of a flat name such as self- 157 certifying identifier as well as the efficient mobility support 158 including the provider mobility. 160 There are several ICN projects which have their own NRS mechanisms as 161 an important component in their architecture. For instance, NetInf, 162 MobilityFirst and IDNet have MDHT [Dannewitz2], DMap [Vu] and BNRS 163 [Hong], respectively. 165 NRS for ICN will be a distributed system as an infrastructure in ICN 166 and will be implemented as a control plane completely separated from 167 data plan. 169 4. Requirements for NRS in ICN 171 In this section, we provide the requirements for designing NRS in ICN 172 in terms of operability, security and manageability, respectively. 174 4.1. Requirements on Operability 176 The requirements on operability aspect are things that should be 177 considered when the key operations of NRS are designed. 179 4.1.1. Scalability 181 The number of NDOs as well as users/publishers is ever-increasing and 182 it will be more than the order of 10^15 by the sensor data in IoT 183 environment. Thus, NRS has to be scalable to support such a large 184 number of NDOs. 186 4.1.2. Low latency 188 The process of the name resolution has to be completed within a 189 minimum delay. If the latency gets too long, then the initial 190 packets of many new sessions may get dropped or it will yield the 191 high response time for end users. For example, in order to browse 192 one web-page which includes several data objects in it, multiple name 193 resolution queries can be processed at the same time and the latency 194 has to be user-tolerant. 196 4.1.3. Fast Update 198 The update process of NRS has to be fast enough to provide up-to-date 199 information since the copies of the data objects are frequently 200 created/disappearing as well as NDOs are moving in a highly dynamic 201 environment. Otherwise, the NRS may return the stale information. 203 4.1.4. Locality 205 In order to achieve the low latency, NRS has to minimize the total 206 traffic and especially the inter-domain traffic. Thus, NRS has to 207 keep the name resolution and data retrieval local, which yields the 208 improvement of network efficiency. 210 4.1.5. Resilience 212 If the resolution service fails, there is mostly no way for the user 213 to reach other end systems as the user knows only their names. Thus 214 NRS has to be resilience to the failures. 216 4.1.6. Fault tolerance / Isolation 218 NRS has to be implemented as a distributed system in order to avoid a 219 single point of failure. In addition, the architecture of NRS has to 220 provide fault isolation, which means that the failure part of NRS has 221 to have an impact only locally. 223 4.2. Requirements on Manageability 225 Requirements on manageability are things that should be considered in 226 terms of the system management aspect. 228 4.2.1. Manageabiliyt 230 NRS has to be manageable since some parts of the system may grow or 231 shrink dynamically and a name resolution server may be added or 232 deleted. 234 4.2.2. Deployability 236 Deployability is important for a real world system. If the NRS can 237 be deployed from the edges, then the deployment can be simplified. 239 4.2.3. Interoperability 241 NRS has to support interoperability between the existing IoT 242 applications since they have their own ways for data management. 244 4.3. Requirements on Security 246 Requirements on security are things that should be considered in 247 terms of the security aspect for both the node and data. 249 4.3.1. Access control 251 A user may want to make a data copy known and accessible only within 252 the local network. In this case, the access control for the 253 information of the data stored in NRS is required. In addition, 254 unauthorized devices may access the NRS network. 256 4.3.2. Authentication 258 Users/nodes that register themselves with NRS server require the 259 authentication to ensure who claims to be. For example, the attacker 260 can act as a fake NRS server which causes disruption or intercepts 261 the data. 263 4.3.3. Data confidentiality 265 NRS has to keep the data confidentiality to prevent a lot of 266 sensitive data from reaching unauthorized data requestor in IoT 267 environment. 269 4.3.4. Data integrity 271 NRS has to keep the data integrity to assure the trustworthiness and 272 accuracy of the information. 274 4.3.5. Privacy 276 When a private data is registered in the system, NRS has to support 277 the privacy to avoid the information leaking. Otherwise, 278 unauthorized entity may disclose the privacy. 280 5. Use case of NRS 282 5.1. Lookup by Name Routing (LBNR) 284 In this subsection, we discuss some use cases of NRS according to the 285 mapping record type: 287 o Name to locator(s): Mapping name to locator(s) is a primary record 288 type in NRS for ICN, where locator denotes routable information. 289 Although name can be hierarchical or flat, this type of NRS is 290 more essential for flat name support. In addition, provider 291 mobility as well as host mobility can be supported efficiently and 292 inherently through this type of mapping. A name registered in NRS 293 can be mapped into multiple locators due to the in-network caches 294 in ICN. 296 o Name to name (alias): Even in RBNR scheme, if provider changes the 297 name to another name which is designed for aggregation by 298 provider, the resolution of the initial name into the aggregated 299 name is required [8]. 301 o Name to IP address: From an incremental deployment perspective, 302 even RBNR would need to map the name onto IP address to access the 303 current Internet (IP network) if necessary. 305 5.2. Route by Name Routing (RBNR) 307 [TBD] 309 5.3. Hybrid Routing (HR) 311 [TBD] 313 6. IANA Considerations 315 There are no IANA considerations related to this document. 317 7. Security Considerations 319 [TBD] 321 8. Acknowledgements 323 [TBD] 325 9. References 327 9.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 335 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 336 "Information-Centric Networking (ICN) Research 337 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 338 . 340 9.2. Informative References 342 [Ahlgren] Ahlgren, B. et al, , "A Survey of Informaiton-Centric 343 Networking", IEEE Communications Magazine vol. 50, no. 7, 344 July 2012. 346 [Xylomenos] 347 Xylomenos, G. et al., , "A Survey of Information-Centric 348 Networking Research", IEEE Communications Surveys and 349 Tutorials vol. 16, no. 2, 2014. 351 [Baccelli] 352 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 353 Wahlisch, "Information Centric Networking in the IoT: 354 Experiments with NDN in the Wild", ACM ICN , September 355 2014. 357 [Amadeo] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named 358 data networking for IoT: An architectural perspective", 359 European Conference on Networks and Communications , July 360 2014. 362 [Quevedo] Quevedo, J., Corujo, D., and R. Aguiar, "A case for ICN 363 usage in IoT environments", IEEE GLOBECOM , 2014. 365 [Amadeo2] Amadeo, M. et al., , "Information-centric networking for 366 the internet of things: challenges and opportunitiesve", 367 IEEE Network vol. 30, no. 2, July 2016. 369 [Zhang] Zhang, Y. et al., , "Requirements and Challenges for IoT 370 over ICN", Internet Draft, draft-zhang-icnrg-icniot- 371 requirements-01 , April 2016. 373 [Jacobson] 374 Jacobson, V. et al., , "Networking named content", 375 Proceedings of the 5th international conference on 376 Emerging networking experiments and technologies , 377 December 2009. 379 [Zhang2] Zhang, L. et al., , "Named data networking", ACM SIGCOMM 380 Computer Communication Review vol. 44, no. 3, July 2014. 382 [Dannewitz] 383 Dannewitz, C. et al., , "Network of Information (NetInf)- 384 An information centric networking architecture", Computer 385 Communications vol. 36, no. 7, April 2013. 387 [Seskar] Seskar, I., Nagaraja, K., Nelson, S., and D. Raychaudhuri, 388 "MobilityFirst Future Internet Architecture Project", 7th 389 Asian Internet Engineering Conference , November 2011. 391 [Jung] Jung, H. et al., , "IDNet: Beyond All-IP Network", ETRI 392 Jouranl vol. 37, no. 5, October 2015. 394 [Dannewitz2] 395 Dannewitz, C., DAmbrosio, M., and V. Vercellone, 396 "Hierarchical DHT-based name resolution for Information- 397 Centric Networks", Computer Communications vol. 36, no. 7, 398 April 2013. 400 [Vu] Vu, T. et al., , "DMap: A Shared Hosting Scheme for 401 Dynamic Identifier to Locator Mapping in the Global 402 Internet", IEEE 32nd International Conference on 403 Distributed Computing Systems , 2012. 405 [Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable 406 Name Resolution System for Information-Centric 407 Networking", ACM ICN , September 2015. 409 Authors' Addresses 411 Jungha Hong 412 ETRI 413 161 Gajeong-Dong Yuseung-Gu 414 Daejeon 305-700 415 Korea 417 Phone: +82 42 860 0926 418 Email: jhong@etri.re.kr 420 Tae-Wan You 421 ETRI 422 161 Gajeong-Dong Yuseung-Gu 423 Daejeon 305-700 424 Korea 426 Phone: +82 42 860 0642 427 Email: twyou@etri.re.kr 428 Yong-Geun Hong 429 ETRI 430 218 Gajeongno, Yuseong 431 Daejeon 305-700 432 Korea 434 Phone: +82 42 860 6557 435 Email: yghong@etri.re.kr