idnits 2.17.1 draft-jeong-ipwave-vehicular-neighbor-discovery-02.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 date (March 5, 2018) is 2243 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-02 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong 3 Internet-Draft Y. Shen 4 Intended status: Standards Track Y. Jo 5 Expires: September 6, 2018 Sungkyunkwan University 6 J. Jeong 7 Samsung Electronics 8 J. Lee 9 Sangmyung University 10 March 5, 2018 12 IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular 13 Networks 14 draft-jeong-ipwave-vehicular-neighbor-discovery-02 16 Abstract 18 This document specifies an extension of IPv6 Neighbor Discovery (ND) 19 for rapid network prefix and service discovery in vehicular networks. 20 It is assumed that a vehicle or a Road-Side Unit (RSU) have an 21 external network interface and their internal network. The extended 22 IPv6 ND called vehicular ND can support vehicle-to-infrastructure 23 communications as well as vehicle-to-vehicle communications. This 24 document defines new ND options to allow a vehicle to announce the 25 network prefixes and services inside its internal network to another 26 vehicle or RSU. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 6, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 5. ND Extension for Prefix and Service Discovery . . . . . . . . 6 67 5.1. Vehicular Prefix Information Option . . . . . . . . . . . 6 68 5.2. Vehicular Service Information Option . . . . . . . . . . 7 69 5.3. Vehicular Neighbor Discovery . . . . . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 8.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 76 discovery-01 . . . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 Vehicular Ad Hoc Networks (VANET) have been researched for the 82 networking on intelligent services in road networks, such as driving 83 safety, efficient driving, and entertainment. To enable this VANET 84 in road networks, Dedicated Short-Range Communications (DSRC) 85 [DSRC-WAVE] has been standardized as IEEE 802.11p [IEEE-802.11p], 86 which is an extension of IEEE 802.11a [IEEE-802.11a], considering the 87 characteristics of vehicular networks, such as high-speed mobility 88 and network fragmentation. Note that IEEE 802.11p was renamed IEEE 89 802.11 Outside the Context of a Basic Service Set (OCB) 90 [IEEE-802.11-OCB] in 2012. For Wireless Access in Vehicular 91 Environments (WAVE) [DSRC-WAVE][WAVE-1609.0], the IEEE has 92 standardized IEEE 1609 family standards, such as IEEE 1609.2, 1609.3, 93 and 1609.4 [WAVE-1609.2][WAVE-1609.3][WAVE-1609.4]. The IEEE 1609 94 standards specify IPv6 as the network-layer protocol [WAVE-1609.3]. 96 Many automobile vendors are replacing Controller Area Networks (CANs) 97 with Ethernet for high-speed interconnectivity among Electronic 98 Control Units (ECUs) in a vehicle. The sensing information of the 99 ECUs can be delivered to the service centers of those automobile 100 ventors for remote diagnosis for driving safety using DSRC between 101 vehicles and Road-Side Units (RSUs) having the Internet connectivity 102 toward the service centers in a vehicular cloud. 104 With this trend, it is time to enable vehicular networking with IPv6 105 to let various Internet-based applications (e.g., remote vehicle 106 diagnosis) run on top of transport-layer protocols, such as TCP, UDP, 107 and SCTP. IPv6 [RFC2460] is suitable for a network layer in 108 vehicular networks in that the protocol has abundant address space, 109 autoconfiguration features, and protocol extension ability through 110 extension headers. 112 To support the interaction between vehicles or between a vehicle and 113 an RSU, this document specifies an extension of IPv6 ND [RFC4861] for 114 rapid network prefix and service discovery in vehicular networks with 115 new ND options. That is, the extended IPv6 ND in this document, 116 which is called vehicular ND, can support not only vehicle-to- 117 infrastructure (V2I) communications but also vehicle-to-vehicle (V2V) 118 communications. 120 2. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 3. Terminology 128 This document uses the terminology described in [RFC4861] and 129 [RFC4862]. In addition, four new terms are defined below: 131 o Road-Side Unit (RSU): A node that has a Dedicated Short-Range 132 Communications (DSRC) device for wireless communications with the 133 vehicles and is connected to the Internet. Every RSU is usually 134 deployed at an intersection so that it can provide vehicles with 135 the Internet connectivity. 137 o Vehicle: A node that has the DSRC device for wireless 138 communications with vehicles and RSUs. Every vehicle may also 139 have a GPS-navigation system for efficient driving. 141 o Traffic Control Center (TCC): A node that maintains road 142 infrastructure information (e.g., RSUs and traffic signals), 143 vehicular traffic statistics (e.g., average vehicle speed and 144 vehicle inter-arrival time per road segment), and vehicle 145 information (e.g., a vehicle's identifier, position, direction, 146 speed, and trajectory). TCC is included in a vehicular cloud for 147 vehicular networks. 149 4. Overview 151 This document specifies an IPv6 ND extension for vehicle-to-vehicle 152 (V2V) or vehicle-to-infrastructure (V2I) networking. 154 Figure 1 shows the V2V networking of two vehicles whose internal 155 networks are Moving Network1 and Moving Network2, respectively. 156 Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and 157 Host2), and the two routers (Router1 and Router2). Vehicle2 has the 158 DNS Server (RDNSS2), the two hosts (Host3 and Host4), and the two 159 routers (Router3 and Router4). 161 It is assumed that Host1 and Host3 are running a Cooperative Adaptive 162 Cruise Control (C-ACC) program for physical collision avoidance. 163 Also, it is assumed that Host2 and Host4 are running a Cooperative 164 On-board Camera Sharing (C-OCS) program for sharing road hazards or 165 obstacles to avoid road accidents. Vehicle1's Router1 and Vehicle2's 166 Router3 use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for 167 V2V networking for various vehicular services. The vehicular 168 applications, such as C-ACC and C-BCS, can be registered into the DNS 169 Server (i.e., RDNSS) through DNSNA protocol in [ID-DNSNA] along with 170 IPv6 ND DNS options in [RFC6106]. 172 Vehicle1's Router1 and Vehicle2's Router3 can know what vehicular 173 applications exist in their internal network by referring to their 174 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 175 what network prefixes exist in their internal network through an 176 intra-domain routing protocoli, such as OSFP. Each vehicle announces 177 its network prefixes and services through ND options defined in 178 Section 5. 180 (*)<..........>(*) 181 | | 2001:DB8:1:1::/64 182 .------------------------------. .------------------------------. 183 | | | | | | 184 | .-------. .------. .-------. | | .-------. .------. .-------. | 185 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 186 | ._______. .______. ._______. | | ._______. .______. ._______. | 187 | ^ ^ ^ | | ^ ^ ^ | 188 | | | | | | | | | | 189 | v v v | | v v v | 190 | ---------------------------- | | ---------------------------- | 191 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 192 | | | | | | 193 | v | | v | 194 | .-------. .-------. | | .-------. .-------. | 195 | | Host2 | |Router2| | | |Router4| | Host4 | | 196 | ._______. ._______. | | ._______. ._______. | 197 | ^ ^ | | ^ ^ | 198 | | | | | | | | 199 | v v | | v v | 200 | ---------------------------- | | ---------------------------- | 201 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 202 .______________________________. .______________________________. 203 Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) 205 <----> Wired Link <....> Wireless Link (*) Antenna 207 Figure 1: Internetworking between Vehicle Networks 209 Figure 2 shows the V2I networking of a vehicle and an RSU whose 210 internal networks are Moving Network1 and Fixed Network1, 211 respectively. Vehicle1 has the DNS Server (RDNSS1), the two hosts 212 (Host1 and Host2), and the two routers (Router1 and Router2). RSU1 213 has the DNS Server (RDNSS2), one host (Host3), the two routers 214 (Router3 and Router4). 216 It is assumed that RSU1 has a collection of servers (Server1 to 217 ServerN) for various services in the road networks, such as road 218 emergency notification and navigation services. Vehicle1's Router1 219 and RSU1's Router3 use 2001:DB8:1:1::/64 for an external link (e.g., 220 DSRC) for I2V networking for various vehicular services. The 221 vehicular applications, such as road emergency notification and 222 navigation services, can be registered into the DNS Server (i.e., 223 RDNSS) through DNSNA protocol in [ID-DNSNA] along with IPv6 ND DNS 224 options in [RFC6106]. 226 Vehicle1's Router1 and RSU1's Router3 can know what vehicular 227 applications exist in their internal network by referring to their 228 own RDNSS through the DNSNA protocol [ID-DNSNA]. They can also know 229 what network prefixes exist in their internal network through an 230 intra-domain routing protocoli, such as OSFP. Each vehicle and each 231 RSU announce their network prefixes and services through ND options 232 defined in Section 5. 234 (*)<..........>(*) 235 | | 2001:DB8:1:1::/64 236 .------------------------------. .---------------------------------. 237 | | | | | | 238 | .-------. .------. .-------. | | .-------. .------. .-------. | 239 | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | 240 | ._______. .______. ._______. | | ._______. .______. ._______. | 241 | ^ ^ ^ | | ^ ^ ^ | 242 | | | | | | | | | | 243 | v v v | | v v v | 244 | ---------------------------- | | ------------------------------- | 245 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 246 | | | | | | 247 | v | | v | 248 | .-------. .-------. | | .-------. .-------. .-------. | 249 | | Host2 | |Router2| | | |Router4| |Server1|...|ServerN| | 250 | ._______. ._______. | | ._______. ._______. ._______. | 251 | ^ ^ | | ^ ^ ^ | 252 | | | | | | | | | 253 | v v | | v v v | 254 | ---------------------------- | | ------------------------------- | 255 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 256 .______________________________. ._________________________________. 257 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 259 <----> Wired Link <....> Wireless Link (*) Antenna 261 Figure 2: Internetworking between Vehicle Network and RSU Network 263 5. ND Extension for Prefix and Service Discovery 265 This section defines two new ND options for prefix and service 266 discovery: (i) the Vehicular Prefix Information (VPI) option and (ii) 267 the Vehicular Service Information (VSI) option. It also describes 268 the ND protocol for such prefix and service discovery. 270 5.1. Vehicular Prefix Information Option 272 The VPI option contains one IPv6 prefix in the internal network. 273 Figure 3 shows the format of the VPI option. 275 0 1 2 3 276 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type | Length | Prefix Length | Distance | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Reserved | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 : Prefix : 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 3: Vehicular Prefix Information (VPI) Option Format 289 Fields: 290 Type 8-bit identifier of the VPI option type as assigned 291 by the IANA: TBD 293 Length 8-bit unsigned integer. The length of the option 294 (including the Type and Length fields) is in units of 295 8 octets. The value is 3. 297 Prefix Length 8-bit unsigned integer. The number of leading bits 298 in the Prefix that are valid. The value ranges 299 from 0 to 128. 301 Distance 8-bit unsigned integer. The distance between the 302 subnet announcing this prefix and the subnet 303 corresponding to this prefix in terms of the number 304 of hops. 306 Reserved This field is unused. It MUST be initialized to 307 zero by the sender and MUST be ignored by the 308 receiver. 310 Prefix An IP address or a prefix of an IP address. The 311 Prefix Length field contains the number of valid 312 leading bits in the prefix. The bits in the prefix 313 after the prefix length are reserved and MUST be 314 initialized to zero by the sender and ignored by 315 the receiver. 317 5.2. Vehicular Service Information Option 319 The VSI option contains one vehicular service in the internal 320 network. Figure 4 shows the format of the VSI option. 322 0 1 2 3 323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type | Length | Reserved1 | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Protocol | Reserved2 | Port Number | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 : Node Address : 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 4: Vehicular Service Information (VSI) Option Format 336 Fields: 337 Type 8-bit identifier of the VSI option type as assigned 338 by the IANA: TBD 340 Length 8-bit unsigned integer. The length of the option 341 (including the Type and Length fields) is in units of 342 8 octets. The value is 3. 344 Reserved1 This field is unused. It MUST be initialized to 345 zero by the sender and MUST be ignored by the 346 receiver. 348 Protocol 8-bit unsigned integer to indicate the upper-layer 349 protocol, such as transport-layer protocol (e.g., 350 TCP, UDP, and SCTP). 352 Reserved2 This field is unused. It MUST be initialized to 353 zero by the sender and MUST be ignored by the 354 receiver. 356 Port Number 16-bit unsigned integer to indicate the port number 357 for the protocol. 359 Service Address 360 128-bit IPv6 address of a node proving this vehicular 361 service. 363 5.3. Vehicular Neighbor Discovery 365 With VPI and VSI options, a node (e.g., vehicle or RSU) can announce 366 the network prefixes and services in its internal network via ND 367 messages, such as Neighbor Solicitation (NS) and Neighbor 368 Advertisement (NA) [RFC4861]. 370 A node periodically announces an NS message containing the VPI and 371 VSI options with its prefixes and services in all-nodes multicast 372 address to reach all neighboring nodes. When another neighboring 373 node receives this NS message, it responds to this NS message by 374 sending an NA message containing the VPI and VSI options with its 375 prefixes and services via unicast toward the NS-originating node. 377 Through this procedure, vehicles and RSUs can rapidly discover the 378 network prefixes and services of the other party without any 379 additional service discovery protocol. 381 6. Security Considerations 383 This document shares all the security issues of the neighbor 384 discovery protocol. This document can get benefits from secure 385 neighbor discovery (SEND) [RFC3971] in order to protect ND from 386 possible security attacks. 388 7. Acknowledgments 390 This work was supported by Next-Generation Information Computing 391 Development Program through the National Research Foundation of Korea 392 (NRF) funded by the Ministry of Science and ICT (2017M3C4A7065980). 393 This work was supported in part by the Global Research Laboratory 394 Program (2013K1A1A2A02078326) through NRF and the DGIST Research and 395 Development Program (CPS Global Center) funded by the Ministry of 396 Science and ICT. 398 8. References 400 8.1. Normative References 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, March 1997. 405 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 406 (IPv6) Specification", RFC 2460, December 1998. 408 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 409 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 410 September 2007. 412 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 413 Address Autoconfiguration", RFC 4862, September 2007. 415 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 416 "IPv6 Router Advertisement Options for DNS Configuration", 417 RFC 6106, November 2010. 419 8.2. Informative References 421 [DSRC-WAVE] 422 Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its 423 Architecture, Design, and Characteristics", 424 IEEE Communications Surveys & Tutorials, 12(4), 2012. 426 [ID-DNSNA] 427 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 428 Autoconfiguration for Internet of Things Devices", draft- 429 jeong-ipwave-iot-dns-autoconf-02 (work in progress), March 430 2018. 432 [IEEE-802.11-OCB] 433 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 434 Access Control (MAC) and Physical Layer (PHY) 435 Specifications", IEEE Std 802.11-2012, February 2012. 437 [IEEE-802.11a] 438 IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access 439 Control (MAC) and Physical Layer (PHY) specifications: 440 High-speed Physical Layer in the 5 GHZ Band", September 441 1999. 443 [IEEE-802.11p] 444 IEEE Std 802.11p, "Part 11: Wireless LAN Medium Access 445 Control (MAC) and Physical Layer (PHY) Specifications 446 Amendment 6: Wireless Access in Vehicular Environments", 447 June 2010. 449 [RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", 450 RFC 3971, March 2005. 452 [WAVE-1609.0] 453 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 454 in Vehicular Environments (WAVE) - Architecture", IEEE Std 455 1609.0-2013, March 2014. 457 [WAVE-1609.2] 458 IEEE 1609 Working Group, "IEEE Standard for Wireless 459 Access in Vehicular Environments - Security Services for 460 Applications and Management Messages", IEEE Std 461 1609.2-2016, March 2016. 463 [WAVE-1609.3] 464 IEEE 1609 Working Group, "IEEE Standard for Wireless 465 Access in Vehicular Environments (WAVE) - Networking 466 Services", IEEE Std 1609.3-2016, April 2016. 468 [WAVE-1609.4] 469 IEEE 1609 Working Group, "IEEE Standard for Wireless 470 Access in Vehicular Environments (WAVE) - Multi-Channel 471 Operation", IEEE Std 1609.4-2016, March 2016. 473 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 474 discovery-01 476 The following changes are made from draft-jeong-ipwave-vehicular- 477 neighbor-discovery-01: 479 o In Section 1, the following sentence is added: Note that IEEE 480 802.11p was renamed IEEE 802.11 Outside the Context of a Basic 481 Service Set (OCB) [IEEE-802.11-OCB] in 2012. 483 o In Section 1, references for WAVE are added as follows: For 484 Wireless Access in Vehicular Environments (WAVE) [DSRC-WAVE] 485 [WAVE-1609.0], the IEEE has standardized IEEE 1609 family 486 standards, such as IEEE 1609.2, 1609.3, and 1609.4 487 [WAVE-1609.2][WAVE-1609.3][WAVE-1609.4]. The IEEE 1609 standards 488 specify IPv6 as the network-layer protocol [WAVE-1609.3]. 490 Authors' Addresses 492 Jaehoon Paul Jeong 493 Department of Software 494 Sungkyunkwan University 495 2066 Seobu-Ro, Jangan-Gu 496 Suwon, Gyeonggi-Do 16419 497 Republic of Korea 499 Phone: +82 31 299 4957 500 Fax: +82 31 290 7996 501 EMail: pauljeong@skku.edu 502 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 504 Yiwen Chris Shen 505 Department of Computer Science and Engineering 506 Sungkyunkwan University 507 2066 Seobu-Ro, Jangan-Gu 508 Suwon, Gyeonggi-Do 16419 509 Republic of Korea 511 Phone: +82 31 299 4106 512 Fax: +82 31 290 7996 513 EMail: chrisshen@skku.edu 514 Younghwa Jo 515 Department of Software Platform 516 Sungkyunkwan University 517 2066 Seobu-Ro, Jangan-Gu 518 Suwon, Gyeonggi-Do 16419 519 Republic of Korea 521 Phone: +82 31 299 4106 522 Fax: +82 31 290 7996 523 EMail: movie_jo@naver.com 525 Junsik Jeong 526 Software R&D Center 527 Samsung Electronics 528 Seoul R&D Campus D-Tower, 56, Seongchon-Gil, Seocho-Gu 529 Seoul 06765 530 Republic of Korea 532 EMail: jun.jeong@samsung.com 534 Jong-Hyouk Lee 535 Sangmyung University 536 Sangmyung University 537 31, Sangmyeongdae-gil, Dongnam-gu 538 Cheonan, NY 31066 539 Republic of Korea 541 EMail: jonghyouk@smu.ac.kr