idnits 2.17.1 draft-jeong-ipwave-vehicular-neighbor-discovery-04.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 (October 22, 2018) is 2013 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) == Outdated reference: A later version (-17) exists of draft-jeong-ipwave-iot-dns-autoconf-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group J. Jeong 3 Internet-Draft Y. Shen 4 Intended status: Standards Track Y. Jo 5 Expires: April 25, 2019 Sungkyunkwan University 6 J. Jeong 7 Samsung Electronics 8 J. Lee 9 Sangmyung University 10 October 22, 2018 12 IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular 13 Networks 14 draft-jeong-ipwave-vehicular-neighbor-discovery-04 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 April 25, 2019. 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-03 . . . . . . . . . . . . . . . . . . . . 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 [RFC8200] 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 [RFC8106]. 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 | v | | v | 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 (RDNSS3), one host (Host5), the two routers 214 (Router5 and Router6). 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 [RFC8106]. 226 Vehicle1's Router1 and RSU1's Router5 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 (*)<........>(*) +------>|Vehicular Cloud| 236 2001:DB8:1:1::/64 | | | +---------------+ 237 +------------------------------+ .---------------------------------+ 238 | v | | v v | 239 | .-------. .------. .-------. | | .-------. .------. .-------. | 240 | | Host1 | |RDNSS1| |Router1| | | |Router5| |RDNSS3| | Host5 | | 241 | ._______. .______. ._______. | | ._______. .______. ._______. | 242 | ^ ^ ^ | | ^ ^ ^ | 243 | | | | | | | | | | 244 | v v v | | v v v | 245 | ---------------------------- | | ------------------------------- | 246 | 2001:DB8:10:1::/64 ^ | | ^ 2001:DB8:20:1::/64 | 247 | | | | | | 248 | v | | v | 249 | .-------. .-------. | | .-------. .-------. .-------. | 250 | | Host2 | |Router2| | | |Router6| |Server1|...|ServerN| | 251 | ._______. ._______. | | ._______. ._______. ._______. | 252 | ^ ^ | | ^ ^ ^ | 253 | | | | | | | | | 254 | v v | | v v v | 255 | ---------------------------- | | ------------------------------- | 256 | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | 257 +______________________________+ +_________________________________+ 258 Vehicle1 (Moving Network1) RSU1 (Fixed Network1) 260 <----> Wired Link <....> Wireless Link (*) Antenna 262 Figure 2: Internetworking between Vehicle Network and RSU Network 264 5. ND Extension for Prefix and Service Discovery 266 This section defines two new ND options for prefix and service 267 discovery: (i) the Vehicular Prefix Information (VPI) option and (ii) 268 the Vehicular Service Information (VSI) option. It also describes 269 the ND protocol for such prefix and service discovery. 271 5.1. Vehicular Prefix Information Option 273 The VPI option contains one IPv6 prefix in the internal network. 274 Figure 3 shows the format of the VPI option. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type | Length | Prefix Length | Distance | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Reserved | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 : Prefix : 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 3: Vehicular Prefix Information (VPI) Option Format 290 Fields: 291 Type 8-bit identifier of the VPI option type as assigned 292 by the IANA: TBD 294 Length 8-bit unsigned integer. The length of the option 295 (including the Type and Length fields) is in units of 296 8 octets. The value is 3. 298 Prefix Length 8-bit unsigned integer. The number of leading bits 299 in the Prefix that are valid. The value ranges 300 from 0 to 128. 302 Distance 8-bit unsigned integer. The distance between the 303 subnet announcing this prefix and the subnet 304 corresponding to this prefix in terms of the number 305 of hops. 307 Reserved This field is unused. It MUST be initialized to 308 zero by the sender and MUST be ignored by the 309 receiver. 311 Prefix An IP address or a prefix of an IP address. The 312 Prefix Length field contains the number of valid 313 leading bits in the prefix. The bits in the prefix 314 after the prefix length are reserved and MUST be 315 initialized to zero by the sender and ignored by 316 the receiver. 318 5.2. Vehicular Service Information Option 320 The VSI option contains one vehicular service in the internal 321 network. Figure 4 shows the format of the VSI option. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Type | Length | Reserved1 | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Protocol | Reserved2 | Port Number | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | | 331 : Node Address : 332 | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Figure 4: Vehicular Service Information (VSI) Option Format 337 Fields: 338 Type 8-bit identifier of the VSI option type as assigned 339 by the IANA: TBD 341 Length 8-bit unsigned integer. The length of the option 342 (including the Type and Length fields) is in units of 343 8 octets. The value is 3. 345 Reserved1 This field is unused. It MUST be initialized to 346 zero by the sender and MUST be ignored by the 347 receiver. 349 Protocol 8-bit unsigned integer to indicate the upper-layer 350 protocol, such as transport-layer protocol (e.g., 351 TCP, UDP, and SCTP). 353 Reserved2 This field is unused. It MUST be initialized to 354 zero by the sender and MUST be ignored by the 355 receiver. 357 Port Number 16-bit unsigned integer to indicate the port number 358 for the protocol. 360 Service Address 361 128-bit IPv6 address of a node proving this vehicular 362 service. 364 5.3. Vehicular Neighbor Discovery 366 With VPI and VSI options, a node (e.g., vehicle or RSU) can announce 367 the network prefixes and services in its internal network via ND 368 messages, such as Neighbor Solicitation (NS) and Neighbor 369 Advertisement (NA) [RFC4861]. 371 A node periodically announces an NS message containing the VPI and 372 VSI options with its prefixes and services in all-nodes multicast 373 address to reach all neighboring nodes. When another neighboring 374 node receives this NS message, it responds to this NS message by 375 sending an NA message containing the VPI and VSI options with its 376 prefixes and services via unicast toward the NS-originating node. 378 Through this procedure, vehicles and RSUs can rapidly discover the 379 network prefixes and services of the other party without any 380 additional service discovery protocol. 382 6. Security Considerations 384 This document shares all the security issues of the neighbor 385 discovery protocol. This document can get benefits from secure 386 neighbor discovery (SEND) [RFC3971] in order to protect ND from 387 possible security attacks. 389 7. Acknowledgments 391 This work was supported by Basic Science Research Program through the 392 National Research Foundation of Korea (NRF) funded by the Ministry of 393 Education (2017R1D1A1B03035885). 395 This work was supported in part by Global Research Laboratory Program 396 through the NRF funded by the Ministry of Science and ICT (MSIT) 397 (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT 398 (18-EE-01). 400 8. References 402 8.1. Normative References 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 408 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 409 September 2007. 411 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 412 Address Autoconfiguration", RFC 4862, September 2007. 414 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 415 "IPv6 Router Advertisement Options for DNS Configuration", 416 RFC 8106, March 2017. 418 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 419 (IPv6) Specification", RFC 8200, July 2017. 421 8.2. Informative References 423 [DSRC-WAVE] 424 Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its 425 Architecture, Design, and Characteristics", 426 IEEE Communications Surveys & Tutorials, 12(4), 2012. 428 [ID-DNSNA] 429 Jeong, J., Ed., Lee, S., and J. Park, "DNS Name 430 Autoconfiguration for Internet of Things Devices", draft- 431 jeong-ipwave-iot-dns-autoconf-03 (work in progress), July 432 2018. 434 [IEEE-802.11-OCB] 435 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 436 Access Control (MAC) and Physical Layer (PHY) 437 Specifications", IEEE Std 802.11-2016, December 2016. 439 [IEEE-802.11a] 440 IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access 441 Control (MAC) and Physical Layer (PHY) specifications: 442 High-speed Physical Layer in the 5 GHZ Band", September 443 1999. 445 [IEEE-802.11p] 446 IEEE Std 802.11p, "Part 11: Wireless LAN Medium Access 447 Control (MAC) and Physical Layer (PHY) Specifications 448 Amendment 6: Wireless Access in Vehicular Environments", 449 June 2010. 451 [RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", 452 RFC 3971, March 2005. 454 [WAVE-1609.0] 455 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 456 in Vehicular Environments (WAVE) - Architecture", IEEE Std 457 1609.0-2013, March 2014. 459 [WAVE-1609.2] 460 IEEE 1609 Working Group, "IEEE Standard for Wireless 461 Access in Vehicular Environments - Security Services for 462 Applications and Management Messages", IEEE Std 463 1609.2-2016, March 2016. 465 [WAVE-1609.3] 466 IEEE 1609 Working Group, "IEEE Standard for Wireless 467 Access in Vehicular Environments (WAVE) - Networking 468 Services", IEEE Std 1609.3-2016, April 2016. 470 [WAVE-1609.4] 471 IEEE 1609 Working Group, "IEEE Standard for Wireless 472 Access in Vehicular Environments (WAVE) - Multi-Channel 473 Operation", IEEE Std 1609.4-2016, March 2016. 475 Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- 476 discovery-03 478 The following changes are made from draft-jeong-ipwave-vehicular- 479 neighbor-discovery-03: 481 o In Figure 1 and Figure 2, the vehicle networks and RSU network are 482 updated. 484 o In Informative References, the reference to IEEE 802.11-OCB is 485 updated. 487 Authors' Addresses 489 Jaehoon Paul Jeong 490 Department of Software 491 Sungkyunkwan University 492 2066 Seobu-Ro, Jangan-Gu 493 Suwon, Gyeonggi-Do 16419 494 Republic of Korea 496 Phone: +82 31 299 4957 497 Fax: +82 31 290 7996 498 EMail: pauljeong@skku.edu 499 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 501 Yiwen Chris Shen 502 Department of Computer Science and Engineering 503 Sungkyunkwan University 504 2066 Seobu-Ro, Jangan-Gu 505 Suwon, Gyeonggi-Do 16419 506 Republic of Korea 508 Phone: +82 31 299 4106 509 Fax: +82 31 290 7996 510 EMail: chrisshen@skku.edu 511 Younghwa Jo 512 Department of Software Platform 513 Sungkyunkwan University 514 2066 Seobu-Ro, Jangan-Gu 515 Suwon, Gyeonggi-Do 16419 516 Republic of Korea 518 Phone: +82 31 299 4106 519 Fax: +82 31 290 7996 520 EMail: movie_jo@naver.com 522 Junsik Jeong 523 Software R&D Center 524 Samsung Electronics 525 Seoul R&D Campus D-Tower, 56, Seongchon-Gil, Seocho-Gu 526 Seoul 06765 527 Republic of Korea 529 EMail: jun.jeong@samsung.com 531 Jong-Hyouk Lee 532 Sangmyung University 533 Sangmyung University 534 31, Sangmyeongdae-gil, Dongnam-gu 535 Cheonan, NY 31066 536 Republic of Korea 538 EMail: jonghyouk@smu.ac.kr