Network Working Group Z. Yan Internet-Draft CNNIC Intended status: Standards Track J. Lee Expires: October 28, 2016 Sangmyung University April 26, 2016 Neighbor discovery to support direct communication in ITS draft-yan-its-nd-00.txt Abstract For C-ACC, Platooning and other typical use cases in ITS, how to establish direct IP communication paths between neighbor vehicles poses "how to discover the neighbors" as the prime issue. In this draft, the issue is analyzed. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 28, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Yan & Lee Expires October 28, 2016 [Page 1] Internet-Draft ITS Vehicle ND April 2016 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Prefix announcement . . . . . . . . . . . . . . . . . . . . . 2 3. Name configuration . . . . . . . . . . . . . . . . . . . . . 3 4. Neighbor discovery . . . . . . . . . . . . . . . . . . . . . 3 5. RSU handover . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Other issues . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Security considerations . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 8.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction As illustrated in [DNS-Autoconf] document, a naming scheme is proposed for the vehicle devices to support the unique name auto- configuration. Based on this document and the mature mDNS protocol, this draft illustrates how to make use of the RSU which announces the local domain name prefix, and how to discover the neighbor vehicles with the infrastructure-less DNS resolution. In this way, a standardized and efficient scheme should be used to retrieve the necessary information of the neighbor vehicles (domain name, IP address, goe-location and so on) for the further direct communications. 2. Prefix announcement The RSU acts as an access router for the static and moving vehicles who want to be connected, and the accessed vehicles reside in the same subnet if they access the same RSU. Based on RFC3646 and RFC6106, the RSU can announce its location based prefix to the vehicles covered by it (with the Domain Search List option). This location based prefix may contain information such as country, city, street and so on, which will function as the "domain_name" of the vehicle device name as spefified in the [DNS-Autoconf] document. Yan & Lee Expires October 28, 2016 [Page 2] Internet-Draft ITS Vehicle ND April 2016 3. Name configuration Referring to [DNS-Autoconf] document, but the main difference is that the name used in this draft is a location-based and temporary name, as the local name in mDNS protocol. 4. Neighbor discovery The following two cases may be considered. o RSU based: When a vehicle wants to locate the potential nearby neighbors and further establish the communication with them, the vehicle will multicast a DNS request message to the local-link as mDNS specifies, with the unicast address as the source address. In this DNS request message, the requested name is "*.domain_name", which means that all the vehicles with the same suffix are required. Besides, to facilitate the further communication, the source link-layer address may be included in the DNS request message, which should be discussed because it will be an extension of DNS message to piggyback additional information. o Ad-hoc based: Vehicles may communicate with each other or sense the front and rear neighbors with DSRC, WiFi, blue-tooth or other short-distance communication schemes. When a vehicle discovers the neighbor vehicles through the periodic scanning, a L2 connection will be established. Then they can join the same all- routers multicast group, and then the discovery can be executed in an infrastructure-less manner. However, how to select the connected neighbors is beyond the scope of this document. Besides, this case poses the challenge to establish and manage multiple L2 connections dynamically. When another vehicle receives this DNS request message, it will check its own domain name with the "domain_name" in the DNS request message, if they match, the vehicle will recognize that it locates near with the requester. Then a DNS response message is unicasted to the requester. In the response message, the IP address is contained in the Answer section, while the geo-location (such as the coordinate information) may be contained in the Additional section. Unicast response is the first recommendation here because it can suppress the flooding, but of course, the DNS response message can also be multicasted as an active announcement of the existence. Then the requester will decide to establish the communication with the information in the DNS response message. Yan & Lee Expires October 28, 2016 [Page 3] Internet-Draft ITS Vehicle ND April 2016 After the neighbor discovery illustrated above, the vehicles should continually exchange their domain name, IP address and geo-location information in order to refresh the established communications. 5. RSU handover During the movement of the vehicle, it may cross different RUSes. When attaching into a new RSU, the new "domain_name" is learned. But the vehicle should keep its previous domain name for some period until that all the communicating neighbors learned its new name. During this period, the vehicle will contain both previous and new domain names in the DNS response message. 6. Other issues TBD 7. Security considerations TBD 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., and P. Gentric, "RTP Payload Format for Transport of MPEG-4 Elementary Streams", RFC 3640, DOI 10.17487/RFC3640, November 2003, . [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, DOI 10.17487/RFC6106, November 2010, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . Yan & Lee Expires October 28, 2016 [Page 4] Internet-Draft ITS Vehicle ND April 2016 8.2. Informative References [DNS-Autoconf] Jeong, J., Lee, S., and J. Park, "DNS Name Autoconfiguration for Internet of Things Devices", draft- jeong-its-iot-dns-autoconf-00, March 2016. Authors' Addresses Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing 100190 China EMail: yan@cnnic.cn Jong-Hyouk Lee Sangmyung University 31, Sangmyeongdae-gil, Dongnam-gu Cheonan Republic of Korea EMail: jonghyouk@smu.ac.kr Yan & Lee Expires October 28, 2016 [Page 5]