Neighbor discovery to support direct communication in ITS
draft-yan-its-nd-00

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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [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,
              <http://www.rfc-editor.org/info/rfc3640>.

   [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,
              <http://www.rfc-editor.org/info/rfc6106>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <http://www.rfc-editor.org/info/rfc6762>.

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]