idnits 2.17.1 draft-choi-cdni-req-intf-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 (October 17, 2013) is 3837 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 101, but not defined == Missing Reference: 'I-D.ietf-leung-cdni-uri-signing-02' is mentioned on line 159, but not defined == Unused Reference: 'KEYWORDS' is defined on line 476, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-cdni-framework (ref. 'I-D.ietf-cdni-framework') ** Downref: Normative reference to an Informational draft: draft-ietf-cdni-requirements (ref. 'I-D.ietf-cdni-requirements') Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Choi 3 Internet-Draft ETRI 4 Intended Status: Standard Track J. Shinn 5 Expires: April 20, 2014 Solbox Inc. 6 J. Sung 7 KT 8 J. Lee 9 SKT 10 J. Koo 11 LGU+ 12 Y. Bang 13 KAIST 14 October 17, 2013 16 Request Interface for Iterative Request Routing Redirection 17 draft-choi-cdni-req-intf-01 19 Abstract 21 This document specifies the request interface between a CDN end-user 22 and an upstream CDN or downstream CDN to request CDN request routing 23 redirection. It specifies the CDNI Request Interface information 24 elements and the actual protocol for exchanging them. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 29, 2012. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Request Interface Function Overview . . . . . . . . . . . . . . 3 63 3. Request Interface Information Elements . . . . . . . . . . . . 3 64 4. Request Procedures . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. HTTP-based Iterative Request Routing Redirection with 66 Loop Prevention . . . . . . . . . . . . . . . . . . . . . 4 67 4.2. DNS-based Iterative Request Routing Redirection with 68 Loop Prevention . . . . . . . . . . . . . . . . . . . . . 9 69 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 70 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 According to the CDNi requirements[I-D.ietf-cdni-requirements] and 79 the CDNI Framework [I-D.ietf-cdni-framework], the need for 80 interconnected CDNs to be able to support iterative and recursive 81 CDNi request routing and implement an access control mechanism that 82 enforces the CSP's distribution policy is described. Recursive CDNi 83 request routing is specified by request routing redirection interface 84 [I-D.ietf-cdni-redirection]. URI signing is specified in URI signing 85 [I-D.leung-cdni-uri-signing]. 87 Meanwhile, both iterative request routing redirection and URI signing 88 require interactions between an end-user and uCDN or dCDN. This 89 implies the need for an interface to support such interactions. 91 To meet the needs, this document specifies an interface called 92 "Request Interface" which resides between end-users and CDN 93 providers. It describes information elements and transport protocols 94 for the interface. 96 1.1. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Request Interface Function Overview 104 Request interface operates between a user agent and CDN provider 105 (either uCDN or dCDN). Since one end of this interface is user 106 application such as web browser, it is desirable not to invent a new 107 protocol for this function. Instead, it uses well-known protocols 108 used by the existing CDN applications such as HTTP and DNS. 110 The main function of this interface is to support the iterative 111 request routing redirection and URI singing. For the iterative 112 request routing redirection, it also supports loop prevention 113 mechanism. 115 3. Request Interface Information Elements 117 To meet the requirements of request routing redirection, we define 118 the term "CDN-Provider-ID". It uniquely identifies each CDN provider 119 during the course of request routing redirection. It consists of 120 "CDN provider name" and "MaxNumRedHops". A pair of an AS number and 121 an additional qualifier is used for CDN provider name. Since more 122 than one CDN providers can belong to the same AS, an additional 123 qualifier is used to guarantee the uniqueness. MaxNumRedHops 124 represents a maximum allowed redirections. The value is decreased 125 once every redirection occurs until it reaches 0. To avoid its usage 126 abuse (e.g., end user or CDN operator can set huge number like 100 or 127 above), a reasonable upper bound has to be agreed among CDN 128 providers. Security aspect of it is for further study. 130 A few examples of the CDN provider names are 100:0 and 200:1. The 131 former means that a CDN provider belong to AS 100 and it is the only 132 CDN provider within that AS. The latter represents the first CDN 133 provider in the AS 200. There are other CDN providers in the same 134 AS. 136 One example of CDN-Provider-ID is "CDN-Provider-Name=100:0 & 137 MaxNumRedHops=10", which means that a CDN provider that belong to AS 138 number 100 and it is the only CDN provider and a maximum allowed 139 redirection is 10. An example how a list of CDN-Provider-IDs can be 140 carried in the URI query string when a certain cascaded request 141 routing redirection occurs is the following. We assume that 142 redirection is cascaded three times: uCDN -> dCDN1 -> dCDN2. dCDN1, 143 then, carries the following URL, "http://cdn.csp.com?uCDN-Provider- 144 ID=100:0&dCDN1-Provider-ID=200:1&MaxNumRedHops=9". Note that 145 MaxNumbRedHops carries the latest number instead of adding in every 146 CDN-Provider-ID to save the space in URI query string. 148 It is applicable for both HTTP-based and DNS redirections. For HTTP- 149 based redirection, we define a HTTP request routing redirection 150 header "CDN-Provider-ID". For each step of redirection, it is 151 attached to the beginning of the provider domain URL. For example, 152 uCDN initiates a redirection with its URL, 153 http://100:0:10.cdn.csp.com. dCDN further attaches its own CDN- 154 Provider-ID in the front when another level of redirection is 155 required. For DNS-based redirection, the CDN-Provider-ID can be 156 attached in the DNS CNAME. 158 For URI singing, detailed format of information elements carried over 159 this interface is defined in [I-D.ietf-leung-cdni-uri-signing-02] 161 4. Request Procedures 163 This section specifies two request procedures: HTTP-based and DNS- 164 based iterative request routing redirection with loop prevention. 166 4.1. HTTP-based Iterative Request Routing Redirection with Loop 167 Prevention 169 In this section, we describe an iterative procedure of HTTP-based 170 request routing redirection with loop prevention. 172 End-User dCDNn dCDNn-1 dCDN1 uCDN 173 |DNS cdn.csp.com | | | | 174 |------------------------------------------------------->| 175 | | | | |(1) 176 |IPaddr of uCDN's Request Router | | | 177 |<-------------------------------------------------------| 178 |HTTP cdn.csp.com | | } | 179 |------------------------------------------------------->| 180 | | | | |(2) 181 |302 peer-uCDN.dCDN1.net/cdn.csp.com?uCDN-Provider-ID | 182 |<-------------------------------------------------------| 183 |DNS peer-uCDN.dCDN1.net | | | 184 |-------------------------------------------->| | 185 | | | |(3) | 186 |IPaddr of dCDN1's Request Router| | | 187 |<--------------------------------------------| | 188 | | | | | 189 |HTTP peer-uCDN.dCDN1.net/cdn.csp.com?uCDN-Provider-ID | 190 |-------------------------------------------->| | 191 | | | |(4) | 192 |302 peer-dCDN1.dCDN2.net/cdn.csp.com?dCDN1-Provider-ID | 193 |<--------------------------------------------| | 194 | | | | | 195 | | ....... |(5) | 196 | | | | | 197 |302 peer-dCDNn-1.dCDNn.net/cdn.csp.com?dCDNn-1-Provider-ID 198 |<-------------------------------| | | 199 | | | | | 200 |DNS peer-dCDNn-1.dCDNn.net | | | 201 |------------------------------->| | | 202 | | |(6) | | 203 |IPaddr of dCDNn's Request Router| | | 204 |<-------------------------------| | | 205 | | | | | 206 |HTTP peer-dCDNn-1.dCDNn.net/cdn.csp.com | | 207 |------------------------------->| | | 208 | | |(7) | | 209 |302 node1.peer-dCDNn-1.dCDNn.net/cdn.csp.com | | 210 |<-------------------------------| | | 211 | | | | | 212 |DNS node1.peer-dCDNn-1.dCDNn.net| | | 213 |------------------>| | | | 214 | | |(8) | | 215 |IPaddr of dCDNn's Delivery Node } | | 216 |<------------------| | | | 217 | | | | | 218 |HTTP node1.peer-dCDNn-1.dCDNn.net/cdn.csp.com| | 219 |------------------>| | | | 220 | |(9) | | | 221 | |DNS dCDNn-acq.dCDNn-1.net| | 222 | |----------->| | | 223 | | |(10) | | 224 | |IPaddr of dCDNn-1's Request Router | 225 | |<-----------| | | 226 | |HTTP dCDNn-acq.dCDNn-1.net?dCDNn-Provider-ID 227 | |----------->| | | 228 | | |(11) | | 229 | | | ....... | | 230 | | | | | 231 | |HTTP dCDN1-acq.uCDN.net?dCDN1-Provider-ID 232 | | | |--------->| 233 | | | | |(12) 234 | | |302 node2.dCDN1.acq.uCDN.net 235 | | | |<---------| 236 | | |DNS node2.dCDN1-acq.uCDN.net 237 | | | |--------->| 238 | | | | |(13) 239 | | |IPaddr of uCDN's Delivery Node 240 | | | |<---------| 241 | | | | |(14) 242 | | | | Data | 243 | | | |<---------| 244 | | | ....... | | 245 |Data | | | | 246 |<------------------| | | | 248 Figure 1: HTTP-based request routing redirection iterative procedure 250 The steps illustrated in the figure are as follows: 252 1. A DNS resolver for uCDN provider processes the DNS request for 253 its customer based on CDN-domain cdn.csp.com. It returns the IP 254 address of a request router in uCDN provider. 256 2. A Request Router for uCDN provider processes the HTTP request 257 and recognizes that the end-user is best served by dCDN1. So it 258 returns a 302 redirect message for a new URL constructed by 259 "stacking" dCDN1's distinguished CDN-domain (peer- 260 uCDN.dCDN1.net) on the front of the original URL. It also adds 261 uCDN's CDN-Provider-ID in the URI query string of the HTTP 262 request message. (e.g., uCDN-Provider-ID=100:0 & 263 MaxNumRedHops=10). This information is not processed by the 264 customer but conveyed in the HTTP message without any 265 modification of the step 4. The details on how it is used for 266 loop prevention is described in the step 4. 268 3. The end-user does a DNS lookup using dCDN1's distinguished 269 CDN-domain (peer-uCDN.dCDN1.net). dCDN1's DNS resolver returns 270 the IP address of a request router for dCDN1. 272 4. The request router for dCDN1 processes the HTTP request. There 273 are two options: redirect further to another dCDN (i.e., 274 cascading the request) or process it by itself. In either 275 cases, it performs loop prevention step first. It checks a list 276 of CDN-provider-IDs in the URI query string: it contains a list 277 of CDN providers which requested redirections so far. If either 278 it contains own CDN provider name or MaxNumRedHops becomes 0, it 279 means that the redirection loop has occurred or the number of 280 redirection hops has reached the maximum. Once loop is 281 detected, details on the next steps is described in the section 282 3. If it is loop free, it either redirects further or processes 283 based on the local policy. For the former, it selects another 284 dCDN provider and and sends an HTTP redirect message with its 285 own CDN-Provider-ID included in its URI query string (e.g., 286 uCDN-Provider-ID=100:0 & dCDN1-Provider-ID=200:1 & 287 MaxNumRedHops=9) attached. For the latter, it selects a 288 suitable delivery node to serve the end-user request, and 289 returns a 302 redirect message for a new URL constructed by 290 replacing the hostname by a subdomain of the dCDN1's 291 distinguished CDN-domain that points to the selected delivery 292 node. Then it goes to the step 6. 294 5. If further redirection is decided, it repeats steps 2 - 4 until 295 it either selects dCDN provider to serve the request or 296 MaxNumRedHops expires. If the former occurs, it resumes the 297 step 6. If the latter occurs, it follows the processes 298 described in the section 3. 300 6. Assuming that dCDNn is selected as a serving dCDN provider, the 301 end-user does a DNS lookup using dCDNn's distinguished 302 CDN-domain (peer-dCDNn-1.dCDNn.net). dCDNn-1's DNS resolver 303 returns the IP address of a request router for dCDNn. 305 7. The request router for dCDN1 processes the HTTP request and 306 selects a suitable delivery node to serve the end-user request, 307 and returns a 302 redirect message for a new URL constructed by 308 replacing the hostname by a subdomain of the dCDNn's 309 distinguished CDN-domain that points to the selected delivery 310 node. 312 8. The end-user does a DNS lookup using dCDNn's delivery node 313 subdomain (node1.peer-dCDNn-1.dCDNn.net). dCDNn's DNS resolver 314 returns the IP address of the delivery node. 316 9. The end-user requests the content from dCDNn's delivery node. 317 In the case of a cache hit, steps 10 ~ 14 below do not happen, 318 and the content data is directly returned by the delivery node 319 to the end-user. In the case of a cache miss, the content needs 320 to be acquired by dCDN from either parent dCDN or uCDN (not the 321 CSP). The distinguished CDN-domain peer-dCDNn-1.dCDNn.net 322 indicates that this content is to be acquired from dCDNn-1; 323 stripping the CDN-domain reveals the original CDN-domain 324 cdn.csp.com and dCDNn may verify that this CDN-domain belongs to 325 a known peer (so as to avoid being tricked into serving as an 326 open proxy). It then does a DNS request for an inter-CDN 327 acquisition CDN-domain as agreed above (in this case, dCDNn- 328 acq.dCDNn-1.net). This process repeats recursively until it 329 finds a CDN provider that can serve the requested content. 331 10. dCDNn-1's DNS resolver processes the DNS request and returns 332 the IP address of a request router in dCDNn-1. 334 11. The request router for dCDNn-1 processes the HTTP request from 335 dCDNn's delivery node. dCDNn-1 request router recognizes that 336 the request is from a peer CDN rather than an end-user because 337 of the dedicated inter-CDN acquisition domain 338 (dCDNn-acq.dCDNn-1.net). It also performs loop prevention 339 process as described in step 4 based on the provided CDN- 340 Provider-ID (e.g., uCDN-Provider-ID=100:0 & dCDN1-Provider- 341 ID=200:1 & ... & dCDNn-Provider-ID=1000:0 & MaxNumRedHops=1). 342 Depending on the number of levels of redirection and 343 availability of contents, the same process repeats until either 344 content serving CDN provider is found or MaxNumRedHps expires. 346 12. Assuming that all intermediate dCDNs also have a cache miss, 347 The request router for uCDN selects a suitable delivery node to 348 serve the inter-CDN acquisition request and returns a 302 349 redirect message for a new URL constructed by replacing the 350 hostname by a subdomain of the uCDN's distinguished inter-CDN 351 acquisition domain that points to the selected delivery node. 353 13. uCDN DNS resolver processes the DNS request and returns the IP 354 address of the delivery node in uCDN. 356 14. uCDN serves content for the requested CDN-domain to dCDN and 357 finally to end-user. Although not shown, it is at this point 358 that uCDN processes the rest of the URL: it extracts information 359 identifying the origin server, validates that this server has 360 been registered, and determines the content provider that owns 361 the origin server. It may also perform its own content 362 acquisition steps if needed before returning the content to 363 dCDN. 365 4.2. DNS-based Iterative Request Routing Redirection with Loop 366 Prevention 368 In this section, we describe an iterative procedure of DNS-based 369 request routing redirection with loop prevention. 371 End-User dCDNn dCDNn-1 dCDN1 uCDN 372 |DNS cdn.csp.com | | | | 373 |------------------------------------------------------->| 374 | | | | | 375 |CNAME uCDNProviderID.dCDN1.cdn.csp.com | |(1) 376 |NS records for dCDN1.cdn.csp.com| | | 377 |<-------------------------------------------------------| 378 |DNS dCDN1.cdn.csp.com | | | 379 |-------------------------------------------->| | 380 | | | | | 381 | | ....... |(2) | 382 | | | | | 383 |CNAME dCDN1.cdn.csp.com | | | 384 |NS records for dCDN1.cdn.csp.com| | | 385 |<-------------------------------| | | 386 |DNS dCDNn.cdn.csp.com | | | 387 |------------------>| | | | 388 | | |(3) | | 389 |IPaddr of dCDNn's Delivery Node } | | 390 |<------------------| | | | 391 | | | | | 392 |HTTP cdn.csp.com | | | | 393 |------------------>| | | | 394 | |(4) | | | 395 | |DNS dCDNn-acq.dCDNn-1.net| | 396 | |----------->| | | 397 | | | | | 398 | | | ....... |(5) | 399 | | | | | 400 | |DNS dCDN1 ProviderID.dCDN1-acq.uCDN.net 401 | | | |--------->| 402 | | | | |(6) 403 | | |IPaddr of uCDN's Delivery Node 404 | | | |<---------| 405 | | | | |(7) 406 | | | | Data | 407 | | | |<---------| 408 | | | ....... | | 409 |Data | | | | 410 |<------------------| | | | 412 Figure 2: DNS-based request routing redirection iterative procedure 414 The steps illustrated in the figure are as follows: 416 1. Request Router for uCDN provider processes the DNS request for 417 CDN- domain cdn.csp.com and recognizes that the end-user is best 418 served by another CDN. (This may depend on the IP address of the 419 user's local DNS resolver, or other information discussed below.) 420 The Request Router returns a DNS CNAME response by "stacking" the 421 distinguished identifier for dCDN1 and uCDN's CDN-Provider-ID 422 (e.g., 100:0.10) onto the original CDN-domain (e.g., 423 dCDN1.cdn.csp.com), plus an NS record that maps dCDN1.cdn.csp.com 424 to dCDN1's Request Router. 426 2. The end-user does a DNS lookup using the modified CDN-domain 427 (i.e., dCDN1.cdn.csp.com). dCDN1 Request Router processes the 428 request and decides to serve the request or redirect further to 429 another CDN provider. It also checks redirection loop. This 430 process iterates until either serving dCDN is selected or 431 MaxNumRedHops expires. In this case, dCDNn is selected as a 432 serving dCDN. If the former occurs, it proceeds to step 3. If 433 the latter occurs, it follows the processes described in the 434 section 3. 436 3. The end-user does a DNS lookup using the modified CDN-domain 437 (i.e., dCDN1.cdn.csp.com). This causes dCDNn's request router 438 returns an IP address of a suitable delivery node. 440 4. The end-user requests the content from dCDNn's delivery node. 441 In the case of a cache hit, steps 5 ~ 7 do not happen, and the 442 content data is directly returned by the delivery node to the 443 end-user. In the case of a cache miss, the content needs to be 444 acquired by dCDNn from either parent dCDN or uCDN (not the CSP). 445 It also performs loop prevention process as described in the step 446 2 based on the provided CDN-Provider-ID (e.g., 447 100:0.200:1.....900:0.1) 449 5. Depending on the number of levels of redirection and availability 450 of contents, the same process repeats until either content 451 serving CDN provider is found or MaxNumRedHps expires. 453 6. Assuming that all intermediate dCDNs also miss cache, uCDN is 454 selected as a content delivery CDN provider. Thus, the request 455 router for uCDN selects a suitable delivery node to serve the 456 inter-CDN acquisition request and returns IP address of the 457 suitable uCDN delivery node. 459 7. uCDN serves content to dCDN1 and further down to end-user. 460 Although not shown, it is at this point that uCDN processes the 461 rest of the URL: it extracts information identifying the origin 462 server, validates that this server has been registered, and 463 determines the content provider that owns the origin server. 465 5 Security Considerations 466 TBD. 468 6 IANA Considerations 470 TBD. 472 7. References 474 7.1. Normative References 476 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, March 1997. 479 [I-D.ietf-cdni-framework] Peterson, L. and B. Davie, "Framework for 480 CDN Interconnection", February 2013. 482 [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content 483 Distribution Network Interconnection (CDNI) Requirements", 484 July 2013. 486 [I-D.ietf-cdni-redirection] Wang, H. and Niven-Jenkins, B., "Request 487 Routing Redirection Interface for Content Distribution 488 Network Interconnection", April 2013. 490 [I-D.leung-cdni-uri-signing] Leung, K. and Le Faucheur, F., "URI 491 Signing for Content Distribution Network Interconnection", 492 May 2013. 494 7.2. Informative References 496 TBD. 498 Authors' Addresses 500 Taesang Choi 501 ETRI 502 161 Gajong-Dong 503 Yusong-Gu, Daejeon 504 Republic of Korea 506 Phone: +82-42-860-5628 507 Email: choits@etri.re.kr 509 John Dongho Shinn 510 Solbox Inc. 512 7F, Haesung Bldg. 747-2 Yeoksam-Dong 513 Kangnam-Gu, Seoul 514 Republic of Korea 516 Phone: +82-10-3005-4785 517 Email: eastsky@solbox.com 519 Jonggyu Sung 520 KT Infra Laboratory 521 463-1, Jeonmin-dong 522 Yuseong-gu, Daejeon 523 Republic of Korea 525 Phone: 82-10-3096-8237 526 Email: jonggyu.sung@kt.com 528 Jongmin Lee 529 SK Telecom 530 11, Euljiro-2ga 531 Jung-gu, Seoul 532 Republic of Korea 534 Phone: 82-10-9429-6260 535 Email: jminlee@sk.com 537 Ja-Ryeong Koo 538 LG U plus Corporation 539 Namdaemunro 5-ga 540 Jung-gu, Seoul 541 Republic of Korea 543 Phone: 82-10-8080-6115 544 Email: wjbkoo@lguplus.co.kr 546 Yong Hwan Bang 547 KAIST 548 8F, N29 Bldg. 373-1 Gusung-Dong 549 Yousong-Gu, Daejeon 550 Republic of Korea 552 Phone: +82-42-350-7516 553 Email: yjhvyp@gmail.com