idnits 2.17.1 draft-kjsun-lisp-dyncast-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 has text resembling RFC 2119 boilerplate text. -- The document date (25 October 2021) is 904 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Sun 3 Internet-Draft Y. Kim 4 Intended status: Informational Soongsil University 5 Expires: 28 April 2022 25 October 2021 7 LISP Support for Dynamic Anycast Routing 8 draft-kjsun-lisp-dyncast-01 10 Abstract 12 Dynamic Anycast (Dyncast) is a new routing approach to support 13 equivalent services running in distributed geolocations and connect 14 to them by considering both network-related metric and service- 15 related metric. In LISP, it is possible to support anycast EIDs and/ 16 or anycast RLOCs without any modification, so it is suitable for 17 providing dyncast routing. In this document, it describes the LISP- 18 based dyncast architecture and related standard works to meet dyncast 19 requirements. 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 28 April 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 Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 57 4. Addressing Dyncast Requirements with LISP . . . . . . . . . . 7 58 4.1. Anycast-based Service Addressing . . . . . . . . . . . . 7 59 4.2. Instance Affinity . . . . . . . . . . . . . . . . . . . . 8 60 4.3. Encoding and Signaling of Metric . . . . . . . . . . . . 9 61 4.4. Dynamic Routing Decisions based using Metrics . . . . . . 10 62 4.5. Supporting Service Dynamism . . . . . . . . . . . . . . . 11 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 6.1. Informative References . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 68 1. Introduction 70 In an environment where equivalent services are distributed in 71 multiple geographic locations, Dynamic-Anycast (Dyncast) enables to 72 perform resource-efficient anycast routing. To support dyncast 73 described in [draft-liu-dyncast-ps-usecases], a unique service 74 identifier that can be assigned to multiple instances in multiple 75 edge environments should be able to be mapped as an actual routable 76 unicast address. Since this concept is similar to the Location/ID 77 separation method already used in the LISP design basis, the LISP 78 protocol can be considered as one of the candidate protocols that can 79 implement dyncast. This draft is proposed to design the LISP-based 80 architecture for Dyncast and analyze the extension method of LISP to 81 meet the requirements defined in [draft-liu-dyncast-reqs] for 82 realizing dynamic anycasting between different LISP sites. 84 2. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document is to be interpreted as described in [RFC2119]. This 89 document uses the terminology described in [RFC6830], 90 [draft-liu-dyncast-ps-usecases], [draft-liu-dyncast-reqs]. Detailed 91 definition of terminologies are written below. 93 Dyncast : As defined in [draft-liu-dyncast-ps-usecases], Dynamic 94 Anycast, taking the dynamic nature of computing resource metrics into 95 account to steer an anycast routing decision. 97 D-Router: A node supporting Dyncast functionalities as described in 98 this document. Namely it is able to understand both network-related 99 and service-instances-related metrics, take forwarding decision based 100 upon and manitain instance affinity, i.e., forwards packets belonging 101 to the same service demand to the same instance. 103 Dyncast Metric Agent (D-MA): A dyncast specific agent able to gather 104 and send metric updates (from both network and instance prespective) 105 but not performing forwarding decisions. May run on a D-Router, but 106 it can be also implementated as a separate module (e.g., a software 107 library) collocated with a service instance. 109 Dyncast Service Endpoint ID (DSEID) : Anycast IP address assigned to 110 the service running on distributed locations. DSEID cannot be routed 111 globally, and it is unique for specific service. Multiple service 112 instances which are same service have a same DSEID. 114 D-BID: Dyncast Binding D-Node, an address to reach a service instance 115 for a given DSEID. It is usually a unicast IP where service 116 instances are attached. Different service instances provide the same 117 service identified through D-SID but with different Dyncast Binding 118 IDs. In the LISP architecture, D-BIDs of same service are replaced 119 to RLOC-set of DSEID. 121 3. Architecture Overview 123 Figure 1 describes the Dyncast architecture based on LISP. In the 124 LISP architecture [draft-ietf-lisp-introduction-13], each edge 125 network has one or more LISP routers deployed. For anycast address, 126 [RFC6830] defines that anycast address can be assigned for both 127 Endpoint ID (EID) and Routing Locator (RLOC) within each of their 128 address spaces. In this draft, we called EID for dynamic anycasting 129 as Dyncast Service Endpoint ID (DSEID), which is assigned to 130 equivalent services across the multiple LISP sites. Similar to the 131 common EID definition, the DSEID cannot be routed globally by itself, 132 and the same DSEID cannot be assigned to different services. In 133 order to forward a packet destined for a DSEID between LISP edges, 134 the addresses of the LISP Egress Tunnel Router (ETR) are used as 135 RLOC-set, which was difined as a Dyncast Binding ID (D-BID) in 136 [draft-li-dyncast-architecture]. Unlike D-BID which is routable and 137 unique for all each service instance, RLOC-set is routable in the 138 underlay but it is not unique values per each service instances. 139 When multiple services are running in the same LISP site, they can be 140 assigned the same RLOC which is xTR of their LISP site. Map-server/ 141 resolver of the LISP control plane can manage mapping information for 142 DESID-to-RLOC-set mappings together with existing EID-to-RLOC 143 mappings. 145 For resource-efficient forwarding decisions across multiple service 146 instances, [draft-li-dyncast-architecture] defines Dyncast Metric 147 Agent (D-MA) which collects metrics related network and service 148 instances. Actual packet forwarding is handled in the Dyncast Router 149 (D-Router) based upon collected metrics with maintaining instance 150 affinity. In the LISP architecture, the D-Router function can be 151 implemented on the LISP xTR, and the D-MA can be deployed as a 152 separate component within the edge for managing service instances, or 153 it can be deployed in combination with the LISP xTR. The LISP 154 control plane is logically centralized and it provides an interface 155 with each LISP router to exchange mapping information. However, it 156 does not mean that the LISP control plane is located in a single 157 physical location, several mechanisms for distributing the mapping 158 system already have been defined. 160 LISP Edge 1 LISP Edge 2 161 '''''''''''''''' ''''''''''''''' 162 ' +----------+ ' ' +----------+' 163 ' | Service | ' ' | Service |' 164 ' | Instance | ' ' | Instance |' 165 ' | (DSEID) | ' ' | (DSEID) |' 166 ' +----------+ ' ' +----------+' 167 ' | ' +---------------------+ ' | ' 168 ' | ' | LISP Control Plane | ' | ' 169 ' +----------+"""'"""+---------------------+" ' | ' 170 ' | D-MA | '"" " " ' | ' 171 ' +----------+ " " " ' | ' 172 ' | " ' " " ' +----------+' 173 ' | " ' " " | D-MA |' 174 ' +----------+ ' " +--------------------+ '" +----------+' 175 ' | LISP-xTR |RLOC" | Core Network |RLOC' | LISP-xTR |' 176 ' |(D-Router)|----"-| (RLOC-Space) |--------|(D-Router)|' 177 ' +----------+ ' " +--------------------+ ' +----------+' 178 ' | ' " '''''''''|''''''''''' 179 ' | ' "' |RLOC ' ' | ' 180 ' | ' '"+--------------------+ ' ' | ' 181 ' | ' ' | LISP-xTR (D-Router)| ' ' | ' 182 ' | ' ' +--------------------+ ' ' | ' 183 ' +----------+ ' ' | ' ' +----------+' 184 ' | Client | ' ' +----------+ ' ' | Client |' 185 ' | (EID) | ' ' | Client | ' ' | (EID) |' 186 ' +----------+ ' ' | (EID) | ' ' +----------+' 187 ' ' ' +----------+ ' ' ' 188 '''''''''''''' '''''''''''''''''' '''''''''''''' 189 LISP Edge 3 191 Figure 1: LISP-based Dyncast Architecture 193 Figure 3 shows an example of LISP-based dyncast deployment where two 194 services each deployed two instances at different edges. In this 195 scenario, two services are assigned an RLOC according to the ETR 196 address of the LISP site. Both Service_A and Service_B instances 197 connected to ETR_2 are assigned RLOC2, which is the RLOC of ETR_2, as 198 a binding ID. According this figure, DSEID-to-RLOC-set mappings can 199 be configured as an example below. 201 DSEID RLOC-set 202 ----------------------------------------------------------- 203 DSEID_A RLOC-set_A ({RLOC2, metric}, {RLOC3, metric}) 204 DSEID_B RLOC-set_B ({RLOC2, metric}, {RLOC3, metric}) 206 Figure 2: DSEID-to-RLOC-set Example 208 In addition to these examples, the RLOC-set can also be used in the 209 form of Explicit Locator Path (ELP) or Run-Length Encoding (RLE) for 210 the encap-path between ETR and ITR. 212 In the case of the edge where ETR_2 is located, as an edge composed 213 only of service instances, the LISP Router function can be operated 214 by being strongly coupled to the edge computing server. In this 215 case, the D-MA function can be implemented on the ETR to insert 216 service-instance-related metrics directly into the LISP protocol 217 packet. In case that a service instance and a client co-exist like 218 an edge where ETR_3 is located, the D-MA entity can be independently 219 deployed proximity of the service instance is running, transparent 220 from the LISP operation for clients. Mapping information update for 221 DSEID is performed through the LISP protocol Map-Register message, 222 and service-instance-related metric can be delivered through in the 223 LISP protocol header or other methods. A method of inserting 224 service-instance-related metric information into the LISP protocol 225 will be discussed later. When the ITR_1 receives a packet destined 226 for the DSEID of the service by service request from the Host_1, the 227 ITR can acquire the RLOC-set of the requested DSEID from the LISP 228 control-plane through the Map-Request message. At the control plane, 229 it may select a proper RLOC on the collected metric information and 230 return it to the ITR or return the RLOC-set of multiple service 231 instances with metric information to the ITR so the ITR selects the 232 proper RLOC in the set. A method for determining an appropriate RLOC 233 will be discussed later. 235 Service_A 236 +-------+ 237 Map-Register D-Router +-|DSEID_A| 238 (DSEID_A, RLOC2, ) +-------+------+ | +-------+ 239 (DESID_B, RLOC2, ,metric>) | ETR_2 | D-MA |-| 240 +-------+------+ | +-------+ 241 | +-|DSEID_B| 242 +------------------+ | RLOC2 +-------+ 243 Host_1 D-Router | +--------------+ |--+ Service_B 244 +--------+ +-------+ | | LISP | | 245 | EID_H1 |--| ITR_1 |----| | Control Plane| | Map-Register 246 +--------+ +-------+ | +--------------+ |(DSEID_A, RLOC3, ) 247 RLOC1| RLOC-Space |(DSEID_B, RLOC3, ) 248 | |--+ RLOC3 249 <---- +------------------+ | 250 Map-Reply D-Router Host_2 251 (DSEID_A, RLOC-set_A, ) +-------+ +--------+ 252 (DSEID_B, RLOC-set_B, ) | ETR_3 |---| EID_H2 | 253 +-------+ +--------+ 254 | 255 +------+ 256 | D-MA | 257 +------+ 258 | 259 +-----+-----+ 260 | | 261 +-------+ +-------+ 262 |DSEID_A| |DSEID_B| 263 +-------+ +-------+ 264 Service_A Service_B 266 Figure 3: LISP-based Dyncast Example Scenario 268 4. Addressing Dyncast Requirements with LISP 270 4.1. Anycast-based Service Addressing 272 To support dyncast routing, the system must provide a method for 273 searching a service identifier allocated as an anycast address and 274 mapping it to a specific unicast address. From this point of view, 275 the LISP is a suitable protocol for separating ID/Location of service 276 and managing mapping information. When the system allocates the same 277 DSEID to each service instance for service equivalency, the LISP can 278 define an anycast address space for the DSEID and assign it to 279 service instances created across multiple sites. Also, the D-BID can 280 be replaced to an RLOC address of LISP xTR that can be routed between 281 edges as unicast. That is, it is necessary to define a separate 282 space for anycast address within the existing EID space and to 283 allocate it in advance so that it can be used in all edge networks 284 where the service instances are located. In the LISP definition, the 285 EID assigned to each service has a globally unique value and, in 286 particular, [RFC6830] defines that anycast address can be assigned 287 within an EID or RLOC block spaces. In each LISP site, same as the 288 EID which is defined to enable internal routing, the DSEID can be 289 able to be routed without the RLOC encapsulation process to the EID 290 within a single site. 292 One of alternative addressing solution is to use anycast-SEID-to- 293 anycast-RLOC mapping. Using this, it is required to register from 294 one place (an SDN controller) or each ETR registering the same RLOC 295 without any merge semantics. So the service is chosen by destination 296 address in a packet (the anycast-EID) which maps to an anycast-RLOC 297 where the underlay takes you to the "closest" LISP site. However, in 298 the dyncast, routing selection is not depending on just distance but 299 also computing resources of each service location. Depending on 300 dynamics of these metrics, anycast-RLOC should be registered/ 301 deregistered at the ETR depending on the absence of specific anycast- 302 EID. Further discussion is required which is more efficient rather 303 than using indirection mapping and update it with unicast-RLOC with 304 metric information. 306 4.2. Instance Affinity 308 For dyncast routing, it is required that the system must set 309 "Instance Affinity" for one or several service requests to provide 310 routing to the same service instance for the same flow. In LISP, the 311 RLOC mapping information for the destination EID is stored in a local 312 cache called Map-cache in the ITR for a certain period of time, and 313 it is maintained for a set time-to-live (TTL) time. Therefore, 314 mapping information for a specific service once requested from a 315 client is generally maintained in the ITR until the corresponding 316 session expires and can be delivered to the RLOC stored in the map- 317 cache entry. However, in order to have a flexible selection of 318 service instances between different flows at the same point, it is 319 additionally required to assign different RLOCs for different flows 320 depending on metrics dynamically changed. For that, it is necessary 321 to enhance ITR Map-cache to maintain destination RLOC for each flow. 322 In [draft-rodrigueznatal-lisp-multi-tuple-eids], it can be supported 323 to store Multi-Tuple Extend-EID mappings. With Multi-Tuple EID 324 mappings, it is possible to provide RLOC affinity depending on its 325 destination DSEID as well as other information such as source EID, 326 protocol or port number. For that, it is required to support multi- 327 stage lookup process, where the multi-tuple EID mappings that point 328 to an DSEID and then there is a DSEID mapping that points to RLOC- 329 set. 331 In addition, although the general TTL value in LISP ITR is defined as 332 24 hours, in dyncast the system requires a shorter TTL time for 333 changing network path depending on dynamically updated network- 334 related and service-instance-related metrics. The LISP support to 335 send a refresh Map-Request before removing map-cache entry. If it 336 needs a shorter TTL to update the map-cache, two options are 337 possible. First option is to send Solicit Map-Request(SMR) for 338 refreshing cache, and another option is to use Pub/Sub which is 339 described in [draft-ietf-lisp-pubsub]. 341 4.3. Encoding and Signaling of Metric 343 In dyncast routing, the one of most important requirements is that it 344 should be able to collect various metrics of service-instances- 345 related as well as network-related, and include them in-network 346 routing decisions. For that, it is necessary to define how to 347 collect these metrics and forward them, and also where to make a 348 decision. In the LISP environment, since that the entire EID-RLOC 349 mapping information is managed in the control plane, one possible 350 scenario is that the D-MA function which collects service-instance- 351 related metrics updates them to the DSEID mapping entry in the LISP 352 control plane. For that, it can be used an encoding method proposed 353 in [draft-farinacci-lisp-name-encoding] that defines to insert 354 specific information such as parameters for a specific EID or RLOC 355 using an ASCII string. Using that, it is possible to encode a string 356 that is pre-defined of a specific metric to interpret in the control 357 plane and send a Map-Request message so that the control plane can 358 select an appropriate RLOC based on it. Another possible option is 359 to use policy distribution by a network controller, which is proposed 360 in [draft-kowal-lisp-policy-distribution]. Using network controller, 361 the ITR could receive and apply the QoS policies that would shape 362 traffic to the correct rate on each ITR RLOC interface. In order to 363 insert service-instance-related metrics from the DSEID side, the D-MA 364 must forward the metrics of the requested service to the LISP ITR so 365 that the metric can be inserted into the header of the Map-Register 366 message. This metric information encoded into the Map-Register 367 message can help the LISP control plane to make multi-tuple mapping 368 entry and sent it to the requested ITR. Once the requested ITR 369 receives these information, it can make a routing decision based on 370 the multi-tuple parameters. 372 4.4. Dynamic Routing Decisions based using Metrics 374 The dyncast system is required that in must make routing decisions 375 for all service requests, and this must be done under an 376 understanding of all metrics. Routing decisions in the LISP can be 377 done with two options which is done in the control plane or ITR by 378 specifying priority and weight values for each RLOC. In case that 379 routing decisions are made in the control plane, the Map-Resolver 380 dynamically sets the priority and weight values of each mapped RLOCs 381 collected from D-MAs, selects a proper RLOC based on them, and 382 forward it to the requested ITR using the Map-Reply message. 383 However, since this centralized approach may not be calculated based 384 on point of requested ITR, the actual routing path may not be 385 optimal. In case that routing decision is determined at the ITR, the 386 LISP control plane may return one or more RLOC values for the 387 requested DSEID to the ITR, including priority and weight values 388 based on the collected metrics. After receiving multiple DBIDs, the 389 ITR stores them in map-cache entry and selects an appropriate one to 390 forward the data packet. For that, a mechanism for estimating 391 appropriate priority and weight values based on both network-related 392 and service-instance-related metrics is required for the control 393 plane or ITR. When DSEID-to-RLOC-set mapping is used, it is noted 394 that if RLOCs in the set have equal priority, the ITR can load-split 395 traffic across RLOCs and that cause to break session connection. So, 396 an ITR that is configured that a particular EID in its map-cache is 397 an DSEID, it should be cared to use an RLOC-set above with each RLOC 398 priority=1. 400 In the dyncast architecture described in 401 [draft-li-dyncast-architecture], the D-Router collects metrics by 402 exchanging metric information of the service identifier between 403 another edge D-Routers and make a decision itself. This approach can 404 minimize the signaling for routing decisions by decentralizing the 405 authority for the anycast routing decision to an entity in the actual 406 packet path, but the signaling for collecting metrics between each 407 D-Router is bound to increase. In contrast, when the LISP is used, 408 it can reduce effectively signaling of collecting metrics from the 409 ITR since that the mapping information for DSEID and RLOC-set can be 410 managed in a centralized control plane. However, if the metrics 411 change too much then the contents of the RLOC-set changes which 412 requires more frequent map-cache updates. So analyzing in depth of 413 this tradeoff remains further studies. 415 4.5. Supporting Service Dynamism 417 For service dynamism, the dyncast system should support different 418 selections for each flow according to a dynamically changing metric 419 while considering various requirements in the selection of a service 420 instance. As mentioned in Section 4.2, 421 [draft-rodrigueznatal-lisp-multi-tuple-eids] can provide the map- 422 cache to be maintained for each flow, so the forwarding path can be 423 dynamically changed to the different service instances by allocating 424 target RLOC to the map-cache entry per-flow according to dynamic 425 changes of metrics. In order to refresh the DSEID-to-RLOC-set 426 mapping upon changing metric, the Solicit Map-Request(SMR) message 427 can be used to update so that the ITR can update the weight and 428 priority for the RLOC which is already received from the Map-server. 429 Additionally, as proposed in [draft-farinacci-lisp-telemetry], 430 telemetry data can be collected between Encapsulating/Decapsulating 431 xTRs of the current flow, which is expected to be used for dynamic 432 service path reselection. 434 5. Security Considerations 436 TBD 438 6. References 440 6.1. Informative References 442 [draft-farinacci-lisp-name-encoding] 443 Farinacci, D., "LISP Distinguished Name Encoding", May 444 2021, . 447 [draft-farinacci-lisp-telemetry] 448 Farinacci, D., Ouissal, S., and E. Nordmark, "LISP Data- 449 Plane Telemetry", May 2021, 450 . 453 [draft-ietf-lisp-introduction-13] 454 Cabellos, A. and D. Saucez, "An Architectural Introduction 455 to the Locator/ID Separation Protocol (LISP)", April 2015, 456 . 459 [draft-ietf-lisp-pubsub] 460 Rodrigues-Natal, A., Ermagan, V., Cabellos, A., Barkai, 461 S., and M. Boucadair, "Publish/Subscribe Functionality for 462 LISP", June 2021, . 465 [draft-kowal-lisp-policy-distribution] 466 Kowal, M., Portoles, M., Jain, A., and D. Farinacci, "LISP 467 Transport for Policy Distribution", September 2021, 468 . 471 [draft-li-dyncast-architecture] 472 Li, Y., Iannone, L., Trossen, D., and P. Liu, "Dynamic- 473 Anycast Architecture", February 2021, 474 . 477 [draft-liu-dyncast-ps-usecases] 478 Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast 479 (Dyncast) Use Cases; Problem Statement", February 2021, 480 . 483 [draft-liu-dyncast-reqs] 484 Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast 485 (Dyncast) Requirements", February 2021, 486 . 489 [draft-rodrigueznatal-lisp-multi-tuple-eids] 490 Rodrigues-Natal, A., Cabellos-Aparicio, A., Barkai, S., 491 Ermagan, V., Lewis, D., Maino, F., and D. Farinacci, "LISP 492 support for Multi-Tuple EIDs", October 2021, 493 . 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", RFC 2119, March 1997, 498 . 500 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 501 Locator/ID Separation Protocol (LISP)", RFC 6830, January 502 2013, . 504 Authors' Addresses 505 Kyoungjae Sun 506 Soongsil University 507 369, Sangdo-ro, Dongjak-gu 508 Seoul 509 06978 510 Republic of Korea 512 Phone: +82 10 3643 5627 513 Email: gomjae@dcn.ssu.ac.kr 515 Younghan Kim 516 Soongsil University 517 369, Sangdo-ro, Dongjak-gu 518 Seoul 519 06978 520 Republic of Korea 522 Phone: +82 10 2691 0904 523 Email: younghak@ssu.ac.kr