Internet DRAFT - draft-petrescu-its-problem
draft-petrescu-its-problem
Network Working Group A. Petrescu
Internet-Draft CEA, LIST
Intended status: Informational D. Liu
Expires: April 21, 2016 Alibaba
C. Perkins
Futurewei
April 19, 2016
Problem Statement for IP in ITS use cases C-ACC and Platooning
draft-petrescu-its-problem-02.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]
