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