idnits 2.17.1 draft-irtf-icnrg-nrsarch-considerations-07.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 date (15 December 2021) is 862 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 477, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ravi-icnrg-ccn-forwarding-label-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 ETRI 5 Expires: 18 June 2022 V. Kafle 6 NICT 7 15 December 2021 9 Architectural Considerations of ICN using Name Resolution Service 10 draft-irtf-icnrg-nrsarch-considerations-07 12 Abstract 14 This document describes architectural considerations and implications 15 related to the use of a Name Resolution Service (NRS) in Information- 16 Centric Networking (ICN). It explains how the ICN architecture can 17 change when an NRS is utilized and how its use influences the ICN 18 routing system. This document is a product of the Information- 19 Centric Networking Research Group (ICNRG). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 18 June 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Implications of NRS in ICN . . . . . . . . . . . . . . . . . 5 58 5. ICN Architectural Considerations for NRS . . . . . . . . . . 6 59 5.1. Name mapping records registration, resolution, and 60 update . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.2. Protocols and Semantics . . . . . . . . . . . . . . . . . 8 62 5.3. Routing System . . . . . . . . . . . . . . . . . . . . . 9 63 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 9.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 Information-Centric Networking (ICN) is an approach to evolving the 75 Internet infrastructure to provide direct access to Named Data 76 Objects (NDOs) by names. In two common ICN architectures, NDN [NDN] 77 and CCNx [CCNx], the name of an NDO is used directly to route a 78 request to retrieve the data object. Such direct name-based routing 79 has inherent challenges in enabling a globally scalable routing 80 system, accommodating producer mobility, and supporting off-path 81 caching. These specific issues are discussed in detail in Section 3. 82 In order to address these challenges, a Name Resolution Service (NRS) 83 has been utilized in the literature as well as the proposals of 84 several ICN projects [Afanasyev] [Zhang2] [Ravindran] [SAIL] [MF] 85 [Bayhan]. 87 This document describes the potential changes in the ICN architecture 88 caused by the introduction of NRS and the corresponding implication 89 to the ICN routing system. It also describes ICN architectural 90 considerations for the integration of an NRS. The scope of this 91 document includes considerations from the perspective of ICN 92 architecture and routing system when using an NRS in ICN. A 93 description of the NRS itself is provided in the companion NRS design 94 considerations document [RFC9138], which provides the NRS approaches, 95 functions and design considerations. 97 This document represents the consensus of the Information-Centric 98 Networking Research Group (ICNRG). It has been reviewed extensively 99 by the Research Group (RG) members who are actively involved in the 100 research and development of the technology covered by this document. 101 It is not an IETF product and is not a standard. 103 2. Terminology 105 * Name Resolution Service (NRS): An NRS in ICN is defined as a 106 service that provides the function of translating a content name 107 or a data object name into some other information such as a 108 routable prefix, a locator, an off-path-cache pointer, or an alias 109 name that is more amenable than the input name to forwarding the 110 object request toward the target destination storing the NDO 111 [RFC9138]. An NRS is most likely implemented through the use of a 112 distributed mapping database system. Domain Name System (DNS) may 113 be used as an NRS. However, in this case, the requirements of 114 frequent updates of NRS records due to the creations of a lot of 115 new NDOs and changes in their locations in the network need to be 116 considered. 118 * NRS server: An NRS comprises the distributed NRS servers storing 119 the mapping records in their databases. NRS servers store and 120 maintain the mapping records that keep the mappings of content or 121 object name to some other information that is used for forwarding 122 the content request or the content itself. 124 * NRS resolver: The client side function of an NRS is called an NRS 125 resolver. The NRS resolver is responsible for initiating name 126 resolution request queries that ultimately lead to a name 127 resolution of the target data objects. NRS resolvers can be 128 located in the consumer (or client) nodes and/or ICN routers. An 129 NRS resolver may also cache the mapping records obtained through 130 the name resolution for later usage. 132 * Name registration: In order to populate the NRS, the content names 133 and their mapping records must be registered in the NRS system by 134 a publisher who has access right to at least one authoritative NRS 135 server or by a producer who generates named data objects. The 136 records contain the mapping of an object name to some information 137 such as other alias names, routable prefixes and locators, which 138 are used for forwarding the content request. Thus, a publisher or 139 producer of contents creates an NRS registration request and sends 140 it to an NRS server. On registration, the NRS server stores (or 141 updates) the name mapping record in the database and sends an 142 acknowledgement back to the producer or publisher that made the 143 registration request. 145 * Name resolution: Name resolution is the main function of the NRS 146 system. It is performed by an NRS resolver which can be deployed 147 on a consumer node or an ICN router. Resolvers are responsible 148 for either returning a cached mapping record (whose lifetime has 149 not expired or alternatively sending a name resolution request 150 toward an NRS server. The NRS server searches for the content 151 name in its mapping record database, and if found, retrieves the 152 mapping record and returns it in a name resolution response 153 message to the NRS resolver. 155 * NRS node: NRS servers are also referred to as NRS nodes that 156 maintain the name records. The terms are used interchangeably. 158 * NRS client: A node that uses the NRS is called an NRS client. Any 159 node that initiates a name registration, resolution, or update 160 procedure is an NRS client. That is, NRS resolvers, ICN client 161 nodes, ICN routers, or producers can be NRS clients. 163 3. Background 165 A pure name-based routing approach in ICN has inherent challenges in 166 enabling a globally scalable routing system, accommodating producer 167 mobility, and supporting off-path caching. In order to address these 168 challenges, an NRS has been utilized in proposals and literature of 169 several ICN projects as follows: 171 * Routing scalability: In ICN, application names identifying 172 contents are intended to be used directly for packet delivery, so 173 ICN routers run a name-based routing protocol to build name-based 174 routing and forwarding tables. Similar to the scalability 175 challenge of IP routing, if non-aggregatable name prefixes are 176 injected into the Default Route Free Zone (DFZ) of ICN routers, 177 they would be driving the uncontrolled growth of the DFZ routing 178 table size. Thus, providing the level of indirection enabled by 179 an NRS in ICN can be an approach to keeping the routing table size 180 under control. The NRS system resolves name prefixes which do not 181 exist in the DFZ forwarding table into globally routable prefixes 182 such as one proposed in NDN [Afanasyev]. Another approach dealing 183 with routing scalability is the Multi-level Distributed Hash 184 Table (MDHT) used in NetInf [Dannewitz]. It provides name-based 185 anycast routing that can support a non-hierarchical namespace and 186 can be adopted on a global scale [Dannewitz2]. 188 * Producer mobility: In ICN, if a producer moves into a different 189 name domain that uses a different name prefix, the request for a 190 content produced by the moving producer with the origin content 191 name must be forwarded to the moving producer's new location. 192 Especially in a hierarchical naming scheme, producer mobility 193 support is much harder than in a flat naming scheme since the 194 routing tables in a broader area need to be updated to track the 195 producer movement. Therefore, various ICN architectures such as 196 NetInf [Dannewitz] and MobilityFirst [MF] have adopted NRS systems 197 to tackle the issues of producers whose location changes. 199 * Off-path caching: In-network caching is a common feature of an ICN 200 architecture. Caching approaches can be categorized into on-path 201 caching and off-path caching, according to the location of caches 202 in relation to the forwarding path from the original content store 203 to a consumer. Off-path caching, sometimes also referred to as 204 content replication or content storing, aims to replicate a Named 205 Data Object in various locations within a network in order to 206 increase the availability of contents, reduce access latency, or 207 both. These caching locations may not be lying along the content 208 forwarding path. Thus, finding off-path cached contents requires 209 more complex forwarding procedures if a pure name-based routing is 210 employed. In order to support access to off-path caches, the 211 locations of replicas are usually advertised into a name-based 212 routing system or into an NRS as described in [Bayhan]. 214 This document discusses architectural considerations and implications 215 of ICN when an NRS is utilized to solve such challenges facing a 216 name-based routing in ICN. 218 4. Implications of NRS in ICN 220 An NRS is not a mandatory part of an ICN architecture, as the 221 majority of ICN architectures uses name-based routing that avoids the 222 need for a name resolution procedure. Therefore, the utilization of 223 an NRS in an ICN architecture changes some architectural aspects at 224 least with respect to forwarding procedures, latency, and security, 225 as discussed below: 227 * Forwarding procedure: When an NRS is included in an ICN 228 architecture, the name resolution procedure has to be included in 229 the ICN overall routing and forwarding architectural procedures. 230 To integrate an NRS into an ICN architecture, there are certain 231 things that have to be decided and specified such as where, when 232 and how the name resolution task is performed. 234 * Latency: When an NRS is included in an ICN architecture, 235 additional latency introduced by the name resolution process is 236 incurred by the routing and forwarding system. Although the 237 latency due to the name resolution is added, the total latency of 238 individual requests being served could be lower if the nearest 239 copies or off-path caches can be located by the NRS lookup 240 procedure. Additionally, there might be a favorable trade-off 241 between the name resolution latency and inter-domain traffic 242 reduction by finding the nearest off-path cached copy of the 243 content. Finding the nearest cache holding the content might 244 significantly reduce the content discovery as well as delivery 245 latency. 247 * Security: When any new component such as an NRS is introduced in 248 the ICN architecture, the attack surface may increase. Protection 249 of the NRS system itself against attacks such as Distributed 250 Denial of Service (DDoS) and spoofing or alteration of name 251 mapping records and related signaling messages may be challenging. 253 5. ICN Architectural Considerations for NRS 255 This section discusses the various items that can be considered from 256 the perspective of ICN architecture when employing an NRS system. 257 These items are related to the registration, resolution, and update 258 of name mapping records, protocols and messages, and integration with 259 the routing system. 261 5.1. Name mapping records registration, resolution, and update 263 When an NRS is integrated in ICN architecture, the functions related 264 to the registration, resolution and update of name mapping records 265 have to be considered. The NRS nodes maintain the name mapping 266 records and may exist as an overlay network over the ICN routers, 267 that is, they communicate to each other through ICN routers. 268 Figure 1 shows the NRS nodes and NRS clients connected through an 269 underlying network. The NRS nodes should be deployed in such a 270 manner that an NRS node is always available at a short distance from 271 an NRS client so that communication latency for the name registration 272 and resolution requested by the NRS client remains very low. The 273 name registration, name resolution and name record update procedures 274 are briefly discussed below. 276 +------------+ +------------+ 277 | NRS Node | | NRS Node | 278 +------------+ +------------+ 279 | | 280 | | 281 +------------+ | | +------------+ 282 | NRS Client |--------------------------------------| NRS Client | 283 +------------+ underlying network +------------+ 285 Figure 1: NRS nodes and NRS clients connected through an 286 underlying network 288 * Name registration: Name registration is performed by the producer 289 (as an NRS client) when it creates a new content. When a producer 290 creates content and assigns a name from its name prefix space to 291 the content, the producer performs the name registration in an NRS 292 node. Name registration may be performed by an ICN router when 293 the ICN architecture supports off-path caching or cooperative 294 caching since involving an NRS may be a good idea for off-path 295 caching. The ICN routers with forwarder caches do not require 296 name registration for their cached content because they lie on the 297 path toward an upstream content store or producer. They will be 298 hit when a future request is forwarded to the content producer by 299 an ICN router lying downstream toward the ICN client node. 300 However, ICN routers performing off-path caching of content must 301 invoke the name registration procedure so that other ICN routers 302 can depend on name resolutions to know about the off-path cache 303 locations. If a content gets cached in many off-path ICN routers, 304 all of them may register the same content names in the same NRS 305 node, resulting in multiple registration actions. In this case, 306 the NRS node adds the new location of the content to the name 307 record together with the previous locations. In this way, each of 308 the name records stored in the NRS node may contain multiple 309 locations of the content. Assigning validity time or a lifetime 310 of each mapping record may be considered especially for the off- 311 path caching contents and managing mobility. 313 * Name resolution: Name resolution is performed by an NRS client to 314 obtain the name record from an NRS node by sending a name 315 resolution request message and getting a response containing the 316 record. In the name-based ICN routing context, the name 317 resolution is needed by any ICN router whose forwarding 318 information base (FIB) does not contain the requested name prefix. 319 Name resolution may also be performed by the consumer (especially 320 in the case where the consumer is multihomed) to forward the 321 content request in a better direction so that it obtains the 322 content from the nearest cache. If the consumer is single homed, 323 it may not bother to perform name resolution, instead depending on 324 either straightforward name-based routing or name resolution by an 325 upstream ICN router. On this case, the consumer creates the 326 content request packet containing the content name and forwards to 327 the nearest ICN router. The ICN router checks its FIB table to 328 see where to forward the content request. If the ICN router fails 329 to know the requested content reachable, it performs name 330 resolution to obtain the name mapping record and adds this 331 information to its FIB. The ICN router may also perform name 332 resolution even before the arrival of a content request to use the 333 name mapping record to configure its FIB. 335 * Name record update: Name record update is carried out when a 336 content name mapping record changes, e.g. the content is not 337 available in one or more of previous locations. The name record 338 update includes the substitution and deletion of the name mapping 339 records. The name record update may take place explicitly by the 340 exchange of name record update messages or implicitly when a 341 timeout occurs and a name record is deemed to be invalid. The 342 implicit update is possible when each record is accompanied by a 343 lifetime value. The lifetime can be renewed only by the 344 authoritative producer or node. The cached mapping records get 345 erased after the lifetime expires unless a lifetime extension 346 indication is obtained from the authoritative producer. 348 5.2. Protocols and Semantics 350 In order to develop an NRS system within a local ICN network domain 351 or global ICN network domain, new protocols and semantics must be 352 designed and implemented to manage and resolve names among different 353 name spaces. 355 One way of implementing an NRS for CCNx is by extending the basic TLV 356 format and semantics [RFC8569] [RFC8609]. For instance, name 357 resolution and response messages can be implemented by defining new 358 type fields in the Interest and Content Object messages [CCNxNRS]. 359 By leveraging the existing CCNx Interest and Content Object packets 360 for name resolution and registration, the NRS system can be deployed 361 with a few ICN protocol changes. However, because of confining the 362 changes to the basic ICN protocol and semantics, the NRS system may 363 not be able to exploit more flexible and scalable designs. 365 On the other hand, an NRS system can be designed independently with 366 its own protocol and semantics like the NRS system described in 367 [Hong]. For instance, the NRS protocol and messages can be 368 implemented by using a RESTful API and the NRS can be operated as an 369 application protocol independent of the rest of the ICN protocol. 371 5.3. Routing System 373 An NRS reduces the routing complexity of ICN architecture compared to 374 pure name-based routing. It does so by permitting the routing system 375 to update the routing table on demand through the help of name 376 records obtained from NRS. The routing system therefore needs to 377 make name resolution requests and process the information returned, 378 such as a prefix, a locator, an off-path-cache pointer, or an alias 379 name, obtained from the name resolution. 381 No matter what kind of information is obtained from the name 382 resolution, as long as it is in the form of a name, the content 383 request message in the routing system may be reformatted with the 384 obtained information. In this case, the content name requested 385 originally by a consumer needs to be involved in the reformatted 386 content request to check the integrity of the binding between the 387 name and the requested content. In other words, the information 388 obtained from the name resolution is used to forward the content 389 request and the original content name requested by a consumer is used 390 to identify the content. Alternatively, the resolved information may 391 be used to build the routing table. 393 The information obtained from name resolution may not be in the form 394 of a name. For example, it may identify tunnel endpoints by IP 395 address and instead be used to construct an IP protocol tunnel 396 through which to forward the content request. 398 6. Conclusion 400 A Name Resolution Service (NRS) is not a mandatory part in an ICN 401 architecture, as the majority of ICN architectures use name-based 402 routing which does not employ a name resolution procedure. However, 403 such name-based routing in ICN has inherent challenges in enabling a 404 globally scalable routing system, accommodating producer mobility, 405 and supporting off-path caching. In order to address these 406 challenges, an NRS system has been introduced in several ICN 407 projects. Therefore, this document describes how the ICN 408 architecture changes when an NRS is utilized and how this affects the 409 ICN routing system. 411 The document defines a few terminologies related to an NRS and 412 explains some inherent challenges of pure name-based routing in ICN 413 such as routing scalability, producer mobility, and off-path caching. 414 This document describes how the ICN architecture would change with 415 respect to procedures, latency, and security when an NRS is utilized. 416 According to the ICN architectural changes, this document describes 417 ICN architectural considerations for NRS such as the functions 418 related to the registration, resolution and update of name mapping 419 records, protocols and semantics to implement an NRS system, and the 420 routing system involving the name resolution. 422 7. IANA Considerations 424 There are no IANA actions required by this document. 426 8. Security Considerations 428 When any new component such as an NRS is introduced in the ICN 429 architecture, the attack surface increases. The related security 430 vulnerability issues are discussed below: 432 * Name space security: In order to deploy an NRS system in ICN 433 architecture, ICN name spaces, which may be assigned by 434 authoritative entities, must be securely mapped to the content 435 publishers and securely managed by them. According to the ICN 436 research challenges [RFC7927], a new name space can also provide 437 an integrity verification function to authenticate its publisher. 438 The issues of namespace authentication and the mapping among 439 different name spaces require further investigation. 441 * NRS system security: An NRS requires the deployment of new 442 entities (e.g. NRS servers) to build distributed and scalable NRS 443 systems. Thus, the entities, e.g., NRS server maintaining a 444 mapping database, could be the focus of attacks by receiving 445 malicious requests from innumerable adversaries comprising a 446 Denial of Service or Distributed Denial of service attacks. In 447 addition, NRS clients in general must trust the NRS nodes in other 448 network domains to some degree and communication among them must 449 also be protected securely to prevent malicious entities from 450 participating in this communication. The history of name 451 resolution data requires to be stored and analyzed as in passive 452 DNS to uncover potential security incidents or discover malicious 453 infrastructures. 455 * NRS protocol and message security: In an NRS system, the protocols 456 to generate, transmit and receive NRS messages related to the name 457 registration, resolution, and record update should be protected by 458 proper security mechanisms. Proper security measures must be 459 provided so that only legitimate nodes can initiate and read NRS 460 messages. These messages must have secured by integrity 461 protection and authentication mechanism so that unauthorized 462 parties cannot manipulate them when being forwarded through the 463 network. Security measures to encrypt these messages should also 464 be developed to thwart all threats to both security and privacy. 465 Numerous problems similar to the security issues of an IP network 466 and DNS can affect the overall ICN architecture. The DNS QNAME 467 minimization type of approach would be suitable for preserving 468 privacy in the name resolution process. Therefore, security 469 mechanisms such as accessibility, authentication, etc., for the 470 NRS system [RFC9138] should be considered to protect not only the 471 NRS system, but also the ICN architecture overall. 473 9. References 475 9.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 483 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 484 "Information-Centric Networking (ICN) Research 485 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 486 . 488 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 489 Networking (CCNx) Semantics", 490 https://www.rfc-editor.org/info/rfc8569 , July 2019. 492 [RFC8609] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 493 Format", https://www.rfc-editor.org/info/rfc8609 , July 494 2019. 496 [RFC9138] Hong, J. et al., "Design Considerations for Name 497 Resolution Service in Information-Centric Networking 498 (ICN)", https://www.rfc-editor.org/info/rfc9138 , November 499 2021. 501 9.2. Informative References 503 [NDN] "NSF Named Data Networking project.", 504 http://www.named-data.net . 506 [CCNx] "Content Centric Networking project.", 507 https://wiki.fd.io/view/Cicn . 509 [Afanasyev] 510 Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to 511 Scale NDN Forwarding", IEEE Global Internet Symposium , 512 April 2015. 514 [Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data 515 Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES, 516 ALGORITHMS, AND APPLICATIONS(NOM) , 2016. 518 [Ravindran] 519 Ravindran, R. et al., "Forwarding-Label support in CCN 520 Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July 521 2017. 523 [SAIL] "FP7 SAIL project.", http://www.sail-project.eu/ . 525 [MF] "NSF Mobility First project.", 526 http://mobilityfirst.winlab.rutgers.edu/ . 528 [Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path 529 Caching in Information-Centric Networks", ACM ICN , 530 September 2016. 532 [CCNxNRS] Hong, J. et al., "CCNx Extension for Name Resolution 533 Service", draft-hong-icnrg-ccnx-nrs-02 , July 2018. 535 [Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable 536 Name Resolution System for Information-Centric 537 Networking", ACM ICN , September 2015. 539 [Dannewitz] 540 Dannewitz, C. et al., "Network of Information (NetInf)-An 541 information centric networking architecture", Computer 542 Communications vol. 36, no. 7, April 2013. 544 [Dannewitz2] 545 Dannewitz, C., DAmbrosio, M., and V. Vercellone, 546 "Hierarchical DHT-based name resolution for Information- 547 Centric Networks", Computer Communications vol. 36, no. 7, 548 April 2013. 550 Acknowledgements 552 The authors would like to thank Dave Oran (ICNRG Co-chair) for very 553 useful reviews and comments on the document and they helped to 554 immeasurably improve the document. 556 Authors' Addresses 558 Jungha Hong 559 ETRI 560 218 Gajeong-ro, Yuseung-Gu 561 Daejeon 563 Email: jhong@etri.re.kr 565 Tae-Wan You 566 ETRI 567 218 Gajeong-ro, Yuseung-Gu 568 Daejeon 570 Email: twyou@etri.re.kr 572 Ved Kafle 573 NICT 574 4-2-1 Nukui-Kitamachi, Tokyo 575 184-8795 576 Japan 578 Email: kafle@nict.go.jp