[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                             Z. Yan
Internet-Draft                                                     CNNIC
Intended status: Standards Track                                  J. Lee
Expires: October 22, 2017                           Sangmyung University
                                                          April 20, 2017

                       Neighbor discovery in ITS


   For C-ACC, platooning and other typical use cases in ITS, a direct IP
   communication between neighbor vehicles is required that poses the
   following two issues: 1) how to discover the neighbor vehicle and the
   required service; and 2) how to discover the link-layer address of
   the neighbor vehicle and server.  This draft presents a solution to
   these problems based on DNS-SD/mDNS [RFC6762][RFC6763].

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 22, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Yan & Lee               Expires October 22, 2017                [Page 1]

Internet-Draft                   ITS ND                       April 2017

   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
   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 management . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Name configuration  . . . . . . . . . . . . . . . . . . . . .   3
   4.  Address configuration . . . . . . . . . . . . . . . . . . . .   3
   5.  Neighbor vehicle and service discovery  . . . . . . . . . . .   4
   6.  Mobility support  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Signaling messages  . . . . . . . . . . . . . . . . . . . . .   5
   8.  Security considerations . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   As illustrated in [DNS-Autoconf], a naming scheme is needed for the
   vehicle devices to support the unique name auto-configuration.  This
   can support the location based communicaton and scalable information
   organization in ITS.  Based on the naming scheme like this and the
   mature DNS-SD/mDNS protocol, this draft illustrates how to discover
   the vehicle or services with DNS resolution.  Before this, we have
   the following assumptions:

   o  Name: vehicle SHOULD have a temporary name which is related to its

   o  Address: vehicle SHOULD have a global IP address which is
      routeable for the IP communications.

   In this way, a standardized, efficient and scalable scheme can be
   used to retrieve the necessary information of the corresponding node
   (domain name, IP address, goe-location and so on) for the further
   communications based on the DNS-SD/mDNS function.  In addition, the
   extended NDP messages (e.g., RA and RS messages) can also be used to
   exchange some required information (e.g., mobile network prefixes,
   link-local address) in ITS in combination with DNS-SD/mDNS [MNPP].

Yan & Lee               Expires October 22, 2017                [Page 2]

Internet-Draft                   ITS ND                       April 2017

2.  Prefix management

   The network architecture which illustrates the prefix management of
   name and address is shown in Figure 1.

       +------------+        +**********+        +------------+
       | Router1    |--------* Internet *--------| Router2    |
       |[IP-Prefix1]|        +**********+        |[IP-Prefix2]|
       +------------+                            +------------+
             |                                        |
             |                                        |
        -----------                              -----------
        |         |                              |         |
        |         |                              |         |
   +-------+    +-------+                   +-------+    +-------+
   | RSU1  |    | RSU2  |                   | RSU3  |    | RSU4  |
   |[Name1]|    |[Name2]|                   |[Name3]|    |[Name4]|
   +-------+    +-------+                   +-------+    +-------+


            Figure 1: Name and address management architecture

   As shown in Figure 1, Router1 and Router2 are two routers which can
   connect to the Internet and hold different IP prefixes.  RSU1 and
   RSU2 are two RSUs under Router1 but hold different name prefixes,
   while RSU3 and RSU4 are two RSUs under Router2 but hold different
   name prefixes.

3.  Name configuration

   The RSU acts as an access router for the static and moving vehicles
   which want to be connected.  Based on [RFC3640], [RFC6106] or
   extended WSA message, the RSU can announce its location based name
   prefix to the vehicles covered by the RSU.  This location based
   prefix may contain information such as country, city, street and so
   on, which will act as the "domain_name" of the vehicle device name as
   spefified in [DNS-Autoconf].

4.  Address configuration

   The RSU may advertise the IP prefix to support the SLAAC operation of
   vehicle devices and movement detection (in the IP layer).  If the
   DHCP is used for the address configuration, RSU also acts as the DHCP

Yan & Lee               Expires October 22, 2017                [Page 3]

Internet-Draft                   ITS ND                       April 2017

5.  Neighbor vehicle and service discovery

   (1) RSU based

   Vehicles may have direct connection with the serving RSU and join the
   same link with the serving RSU.  Then the RSU can maintain the
   registered vehicle or service in its serving domain.  Otherwise, the
   RSU acts as a relay node for discovering in a proxy manner.

   When a vehicle wants to locate the potential nearby neighbor and
   further establish the communication, the vehicle will trigger the
   direct unicast query to port 5353 or legacy unicast DNS query to the
   RSU.  RSU may response directly if it has the related information,
   otherwise, the RSU multicasts the DNS query to multicast group to
   retrieve the related information.  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 verhicle or service existence.

   (2) 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 technologies, connecting each other in the Ad-hoc
   manner.  Then the discovery can be executed in an infrastructure-less
   manner with the following phases, as specified in mDNS.

   o  Probing: When a vehicle starts up, wakes up from stalls or
      topology changes (after configuration of the name and address), it
      should probe the availability of the service it announced.  Then
      the vehicle periodically announces the service and its existence
      with unsolicited multicast DNS response containing, in the Answer
      Section, all of its service and name and address.  The vehicle
      also updates the related information actively if there is any

   o  Discovering: To support the service and neighbor vehicle discovery
      in the dynamic and fragmentation-possible environment in VANET,
      different query modes of mDNS can be used for different scenarios:
      1) One-Short Multicast DNS Query can be used to locate a specific
      service (for example). 2) Continuous Multicast DNS Query can be
      used to locate the nearby vehicles which are moving (for example).

   o  Refreshing: After the neighbor discovery illustrated above, the
      vehicles should continually exchange their name, IP address and
      geo-location information in order to refresh the established
      communications.  For example, the Multiple Questions Multicast
      Responses can be used to update the caches of receivers

Yan & Lee               Expires October 22, 2017                [Page 4]

Internet-Draft                   ITS ND                       April 2017

      efficiently and Multiple Questions Unicast Responses can be used
      to support the fast bootstrapping when new vehicle joins.

   o  Goodbye: When the vehicle arrives at its destination, stalls
      temporarily or shuts down its communication or sensing devices, it
      will announce the service suspending and its inexistence with
      unsolicited multicast DNS response packet, giving the same RRs
      (containing its name and address), but TTL of zero.

6.  Mobility support

   During the movement of the vehicle, it may cross different RUSes.
   When attaching into a new RSU, the new domain prefix and new IP
   prefix may be learned.  Generally, there are two main cases for the

   o  Name prefix changes and IP prefix remains, as shown in Figure 1,
      the vehicle hands over from RSU1 to RSU2.  The vehicle will
      configure new name from RSU2 and update the new name in the local
      database (e.g., RSU).  But the vehicle should keep its previous
      name for a period until that all the communicating neighbors learn
      its new name.  During this period, the vehicle will contain both
      previous and new domain names in the DNS response message.

   o  Both name and IP prefixes change, as shown in Figure 1, the
      vehicle hands over from RSU2 to RSU3.  The vehicle will configure
      new name and new IP address from RSU3 and update the IP address
      (and the name) in the local database, in addition, IP-layer
      mobility management protocols may be used to maintain the IP
      connectivity in this case.

7.  Signaling messages

   To facilitate the further communication, the link-layer address and
   geo-information may be included in the DNS message in a piggyback
   manner.  Otherwise, these information may be obtained through the
   following NDP or other procedures.

8.  Security considerations

   In order to reduce the DNS traffic on the wireless link and avoid the
   unnecessary flooding, the related schemes in mDNS can be used, such
   as: Known-Answer Suppression, Multipacket Known-Answer Suppression,
   Duplicate Question Suppression and Duplicate Answer Suppression.

   In order to guarantee the origination of the DNS message and avoid
   the DNS message tampering, the security consideration in mDNS should
   also be adopted.

Yan & Lee               Expires October 22, 2017                [Page 5]

Internet-Draft                   ITS ND                       April 2017

9.  References

9.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,

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,

9.2.  Informative References

              Jeong, J., Lee, S., and J. Park, "DNS Name
              Autoconfiguration for Internet of Things Devices",  draft-
              jeong-ipwave-iot-dns-autoconf-00, March 2017.

   [MNPP]     Lee, J., Tsukada, M., and T. Ernst, "Mobile Network Prefix
              Provisioning",  draft-jhlee-mext-mnpp-00, October 2009.

Authors' Addresses

   Zhiwei Yan
   No.4 South 4th Street, Zhongguancun
   Beijing  100190

   EMail: yan@cnnic.cn

Yan & Lee               Expires October 22, 2017                [Page 6]

Internet-Draft                   ITS ND                       April 2017

   Jong-Hyouk Lee
   Sangmyung University
   31, Sangmyeongdae-gil, Dongnam-gu
   Republic of Korea

   EMail: jonghyouk@smu.ac.kr

Yan & Lee               Expires October 22, 2017                [Page 7]

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/