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

Versions: 00 01 02 03

Network Working Group                                        A. Petrescu
Internet-Draft                                                 CEA, LIST
Intended status: Informational                                    D. Liu
Expires: January 8, 2017                                         Alibaba
                                                              C. Perkins
                                                               Futurewei
                                                            July 8, 2016


     Problem Statement for IP in ITS use cases C-ACC and Platooning
                   draft-petrescu-its-problem-03.txt

Abstract

   Two vehicle-to-vehicle communications use cases are discussed, namely
   Cooperative Adaptive Cruise Control (C-ACC) and Platooning.  For
   these two use cases, the problems are identified that pertain to
   development with Internet protocols and connectivity.

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 April 21, 2016.

Copyright Notice

   Copyright (c) 2015 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
   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



Petrescu, et al.         Expires April 21, 2016                 [Page 1]


Internet-Draft    C-ACC / Platooning Problem Statement      October 2015


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  The Problem . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Discovery Sub-Problem . . . . . . . . . . . . . . . . . .   5
     3.2.  Prefix Exchange sub-Problem . . . . . . . . . . . . . . .   5
     3.3.  Prefix Exchange with the First-hop Infrastructure . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  ChangeLog  . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Recent years have seen growing interest in vehicle-to-vehicle
   communications.  C-ACC and Platooning are two use cases that hold
   promise for major increases in vehicle safety as well as fuel
   efficiency.  In this document we explore the problem of realizing
   solutions for these use cases using well-known Internet protocols and
   applications.

2.  Terminology

   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 [RFC2119].

   This document defines the following terminology:

   Cooperative Adaptive Cruise Control (C-ACC)
      The automation of speed maintenance in several cooperating
      vehicles (increase torque if uphill, smoothly brake downhill, such
      as to maintain constant speed).  The term "Adaptive Cruise
      Control" was used earlier in related ISO standards.  The concept
      of C-ACC aims at the same level of automation but in a cooperative
      manner between several vehicles: while in CC mode, when a vehicle
      in front slowly decelerates, this vehicle will also do, such as to
      maintain distance, and relieve driver from taking over control.

   edge router




Petrescu, et al.         Expires April 21, 2016                 [Page 2]


Internet-Draft    C-ACC / Platooning Problem Statement      October 2015


      An edge router connects the internal networks of the vehicle to
      the external world, including road side stations, wide-area
      Internet connectivity, and the edge routers of other vehicles.

   Platooning
      Platooning is a concept related to larger vehicles following each
      other.  The goal in this case is more than just comfort - large
      gains are expected in terms of gas consumption.  When large
      vehicles can follow each other at small distance the air-drag is
      much lower, reducing gas consumption, tire use, and more.

3.  The Problem

   Several use-cases in Intelligent Transportation Systems (ITS) may be
   implementable using the TCP/IP suite of protocols and consequently
   benefit from the global availability of Internet connectivity.
   Cooperative Adaptive Cruise Control (C-ACC) and Platooning are two
   such use cases.  They both require low-latency data exchanges between
   vehicles.  For these use cases, connecting the vehicles through long-
   range cellular networks typically incurs too much delay.  Instead, it
   is necessary to connect vehicles directly, by using shorter-range
   communication technologies.

   A vehicle embeds several IP devices, forming a stable network.
   Typically, Ethernet cables are run through a car, together with the
   CAN networks.  Computers in an automobile perform an ever-growing
   variety of sensing and control tasks.  Typically one edge router is
   in charge of wireless communications outside the car, potentially via
   multiple technologies.

   The problem is how best to establish low-latency IP communication
   paths between the computer on the networks embedded in two or more
   neighboring and potentially fast-moving vehicles.  The C-ACC use-case
   illustrates this problem.  When a vehicle sends its coordinates to
   the vehicle behind it, the latter vehicle may subsequently act by
   braking under certain circumstances, which then must trigger
   immediate responses from the other cooperating vehicles.














Petrescu, et al.         Expires April 21, 2016                 [Page 3]


Internet-Draft    C-ACC / Platooning Problem Statement      October 2015


               Vehicle 1                             Vehicle 2
                                    e.g.
                              o)) LTE D2D  ((o
                              |   802.11p    |
                              |     LiFi     |
                              |              |
         +------+          +--+--+        +--+--+     +----------+
         |GPS PC|          | eR1 |        | eR2 |     |Braking PC|
         +--+---+          +--+--+        +--+--+     +-----+----+
            |                 |              |              |
            |                 |              |              |
            |    Ethernet     |              |  Ethernet    |
           -+-----------------+-          ---+--------------+-----
             2001:db8:1::/40                      2001:db8:2::/40


                 Figure 1: Two vehicles with wireless link

   Figure 1 depicts two vehicles in close range.  Their respective edge
   routers (eR1 and eR2) can exchange data by using a short-range link-
   layer wireless technology such as LTE D2D, IEEE 802.11p, Bluetooth,
   LiFi, among others.

   The Ethernet (egress) interfaces of eR1 and eR2 form a single IP
   subnet.  In the figure, there is only one IP hop (a wireless link)
   between eR1 and eR2.

   Within each vehicle there is at least one subnet, but there are
   potentially several distinct IP subnets in each vehicle.  For the
   case in which there is only one subnet in each vehicle, the IP hop
   count between one IP device in one vehicle and the IP device in
   another vehicle is at most 3: 1 IP hop in each vehicle and 1 IP hop
   between the vehicles.

   As an application example, the "GPS PC" in one vehicle sends IP
   datagrams containing its coordinates to the Braking PC in the other
   vehicle, controling braking.  The IP datagrams are sent through the
   respective edge routers.

   In order for GPS PC to reach Braking PC it is necessary that the two
   edge routers have forwarding information about their respective
   subnets: eR1 must learn that prefix 2001:db8:2::/40 is reachable
   through eR2, and vice-versa.  It is thus necessary that they exchange
   routing information.  Otherwise, the GPS PC and Braking PC can not
   reach one another.






Petrescu, et al.         Expires April 21, 2016                 [Page 4]


Internet-Draft    C-ACC / Platooning Problem Statement      October 2015


   The problem is divided in a discovery sub-problem (how edge routers
   discover each other) and a prefix exchange sub-problem (how edge
   routers exchange routing information).

3.1.  Discovery Sub-Problem

   Various information needs to be discovered to set up the IP
   communication between the vehicles.  The information that needs to be
   discovered by an edge router includes link layer, MAC layer and IP
   layer information.

   For link layer information, wireless link layer parameters need to be
   obtained.  For example, determining the power level of received
   wireless frames can be used to determine the distance between two
   neighboring vehicles.

   For MAC layer information, the MAC address information of the
   neighboring edge router needs to be discovered.

   For IP layer information, in the above figure, eR1 needs to discover
   the IP address and IP prefix of eR2 and eR2 also needs to discover
   the IP address and IP prefix of eR1.  Other multicast related
   information may also need to be discovered.

   Service-related information sometimes is also needed.  For example, a
   vehicle might wish to indicate that it offers video translation or
   VPN services to headquarters.

3.2.  Prefix Exchange sub-Problem

   As mentioned earlier, establishing single-hop forwarding between two
   neighboring vehicles is part of the overall problem for supporting
   C-ACC and platooning.

   There are two modes of operating a V2V topology:

   o  Peer-to-peer operation: one vehicle connects with another vehicle
      and exchanges information in a peer basis.

   o  master-slave operation: one slave vehicle connects to another
      vehicle which is considered to master several other slave
      vehicles.  The slave vehicle may request an allocation of
      prefixes, and then uses the master vehicle as a default router.
      Master-slave operation is not considered in this document.

   The peer-to-peer operation of a V2V topology is an important aspect
   of ITS use cases such as C-ACC and Platooning.  This mode of
   operation allows each vehicle to send and receive application data



Petrescu, et al.         Expires April 21, 2016                 [Page 5]


Internet-Draft    C-ACC / Platooning Problem Statement      October 2015


   (coordinates, speed) as IP packets, without the need of assistance
   from fixed infrastructure.  Each vehicle is preconfigured with a
   unique IPv6 prefix and each computer in a vehicle is identified by a
   unique IPv6 address.

   In order for one computer in one vehicle to reach another computer in
   another vehicle the edge routers in each vehicle have to learn the
   IPv6 prefix (and/or the IPv6 address) of the other vehicles.  A
   prefix-exchange mechanism is needed, otherwise the IP communication
   cannot be established.

   After each vehicle has informed the other vehicles nearby about its
   prefix, the forwarding tables of each vehicle must be updated to
   contain the tuple [prefix; IP address] of the other vehicles.  The
   updating has to deal with situations when vehicles leave the network,
   otherwise numerous ICMP Destination Unreachable messages may cause
   undesirable interference on the inter-vehicle medium.

   It is likely that vehicles will join and leave the set of cooperating
   vehicles for cruise control, and similarly for vehicles in a platoon.
   Then the neighbor relationships would need to be re-evaluated, and
   subnet reachability information would also require updates.

3.3.  Prefix Exchange with the First-hop Infrastructure

   In order to establish bidirectional communications with the fixed
   infrastructure, edge routers must have a topologically correct prefix
   with the first hop router of the chosen access network for the fixed
   infrastructure.  In order for this to happen, the edge router must
   first discover the access router for the chosen access network.

   In order to be effective, the discovery and exchange operations need
   to be completed very quickly in order to serve the needs of fast-
   moving vehicles.

4.  Security Considerations

   As is the case with typical V2V use cases, privacy is a very
   important consideration.  Information identifying the vehicle could
   very likely be used to get accurate information about the identity of
   the driver, and thus the identifiers used for the use cases in this
   document should be randomly assigned for the purposes required
   without any necessary correspondence to the actual vehicle
   identification.

   Other information stored in each vehicle's networks must not be
   inadvertently disclosed by protocol errors or by misuse of supported
   applications.



Petrescu, et al.         Expires April 21, 2016                 [Page 6]


Internet-Draft    C-ACC / Platooning Problem Statement      October 2015


5.  IANA Considerations

   There are no IANA actions specified within this document.

6.  References

6.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>.

6.2.  Informative References

   [I-D.liu-its-scenario]
              Liu, D., "Scenario of Intelligent Transportation System",
              draft-liu-its-scenario-00 (work in progress), March 2015.

   [I-D.petrescu-ipv6-over-80211p]
              Petrescu, A., Pfister, P., Benamar, N., and T.
              Leinmueller, "Transmission of IPv6 Packets over IEEE
              802.11p Networks", draft-petrescu-ipv6-over-80211p-02
              (work in progress), June 2014.

Appendix A.  ChangeLog

   The changes are listed in reverse chronological order, most recent
   changes appearing at the top of the list.

   o  Added text for Abstract, Introduction, Terminology, Security
      Considerations, and IANA Considerations.

   o  Changed terminology from "embed router" to "edge router".

   o  Added text for "Prefix Exchange with the First-hop
      Infrastructure."

Authors' Addresses

   Alexandre Petrescu
   CEA, LIST
   CEA Saclay
   Gif-sur-Yvette , Ile-de-France   91190
   France

   Phone: +33169089223
   Email: Alexandre.Petrescu@cea.fr



Petrescu, et al.         Expires April 21, 2016                 [Page 7]


Internet-Draft    C-ACC / Platooning Problem Statement      October 2015


   Dapeng Liu
   Alibaba
   Beijing , Beijing   100022
   China

   Phone: +86-13911788933
   Email: max.ldp@alibaba-inc.com


   Charles E. Perkins
   Futurewei Inc.
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +1-408-330-4586
   Email: charliep@computer.org


































Petrescu, et al.         Expires April 21, 2016                 [Page 8]


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