One document matched: draft-petrescu-its-problem-01.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- <?xml version="1.0" encoding="US-ASCII"?> -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
<!ENTITY RFC2119 PUBLIC ""
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY DRAFT-IPv6-over-11p SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.petrescu-ipv6-over-80211p.xml">
<!ENTITY DRAFT-liu SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.liu-its-scenario.xml">
]
>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<rfc category="info"
docName="draft-petrescu-its-problem-01.txt"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic ipr values:
trust200902, noModificationTrust200902,
noDerivativesTrust200902, or pre5378Trust200902 you can add the
attributes updates="NNNN" and obsoletes="NNNN" they will
automatically be output with "(if approved)" -->
<front>
<title abbrev="C-ACC / Platooning Problem Statement">
Problem Statement for IP in ITS use cases C-ACC and Platooning
</title>
<author initials='A.' surname="Petrescu" fullname='Alexandre Petrescu'>
<!-- role=""> -->
<organization>CEA, LIST</organization>
<address>
<postal>
<street>
CEA Saclay
</street>
<city>
Gif-sur-Yvette
</city>
<region>
Ile-de-France
</region>
<code>
91190
</code>
<country>
France
</country>
</postal>
<phone>
+33169089223
</phone>
<email>
Alexandre.Petrescu@cea.fr
</email>
</address>
</author>
<author initials='D.' surname='Liu' fullname='Dapeng Liu'>
<organization>
Alibaba
</organization>
<address>
<postal>
<street>
</street>
<city>
Beijing
</city>
<region>
Beijing
</region>
<code>
100022
</code>
<country>
China
</country>
</postal>
<phone>
+86-13911788933
</phone>
<email>
max.ldp@alibaba-inc.com
</email>
</address>
</author>
<author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
<organization abbrev="Futurewei">Futurewei Inc. </organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>95050</code>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1-408-330-4586</phone>
<email>charliep@computer.org</email>
</address>
</author>
<date/>
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc, IETF is fine for
individual submissions. If this element is not present, the
default is "Network Working Group", which is used by the RFC
Editor as a nod to the history of the IETF. -->
<keyword>
V2V, Vehicle-to-Vehicle communications, LTE D2D, IPv6 prefix
exchange, router discovery, IP paths, neighboring vehicles,
Intelligent Transportation Systems, ITS
</keyword>
<!-- Keywords will be incorporated into HTML output files in a
meta tag but they have no effect on text or nroff output. If
you submit your draft to the RFC Editor, the keywords will be
used for the search engine. -->
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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.
</t>
</section>
<section title="Terminology">
<t>
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
<xref target="RFC2119">RFC 2119</xref>.
</t>
<t>This document defines the following terminology:</t>
<t><list style="hanging">
<t hangText="Cooperative Adaptive Cruise Control (C-ACC)"><vspace />
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.
</t>
<t hangText="edge router"><vspace />
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.
</t>
<t hangText="Platooning"><vspace />
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.</t>
</list></t>
</section>
<section anchor="problem" title="The Problem">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
<figure align="center" anchor="two_ERs"
title="Two vehicles with wireless link">
<artwork align="center">
<![CDATA[
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
]]>
</artwork>
</figure>
</t>
<t>
<xref target="two_ERs"/> 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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).
</t>
<section title="Discovery Sub-Problem">
<t>
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.
</t>
<t>
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.
</t>
<t>
For MAC layer information, the MAC address information of the
neighboring edge router needs to be discovered.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Prefix Exchange sub-Problem">
<t>
As mentioned earlier, establishing single-hop forwarding
between two neighboring vehicles is part of the overall
problem for supporting C-ACC and platooning.
</t>
<t>
There are two modes of operating a V2V topology:
<list style='symbols'>
<t>
Peer-to-peer operation: one vehicle connects with
another vehicle and exchanges information in a
peer basis.
</t>
<t>
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.
</t>
</list></t>
<t>
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 (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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<!-- Some would say, the following belongs in a "solution" document.
<t>
The problem is thus how to realize this prefix exchange.
</t>
-->
</section>
<section title="Prefix Exchange with the First-hop Infrastructure">
<t>
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.
</t>
<t>
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.
</t>
</section>
</section> <!-- End of section anchor="problem" title="The Problem" -->
<!--
<section title="Conclusions">
<t>
conclusions
</t>
</section>
Not clear that a "Conclusions" section is really needed. -->
<section anchor="Security" title="Security Considerations">
<t>
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.
</t>
<t>
Other information stored in each
vehicle's networks must not be inadvertently disclosed by
protocol errors or by misuse of supported applications.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
There are no IANA actions specified within this document.
</t>
</section>
<!--
<section anchor="Contributors"
title="Contributors">
<t>
contributors
</t>
</section>
NONE YET -->
<!--
<section anchor="Acknowledgements"
title="Acknowledgements">
<t>
acks
</t>
</section>
NONE YET -->
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&DRAFT-IPv6-over-11p;
&DRAFT-liu;
</references>
<section anchor='changelog'
title='ChangeLog'>
<t>
The changes are listed in reverse chronological order, most
recent changes appearing at the top of the list.
</t>
<t>
<list style='symbols'>
<t>
Added text for Abstract, Introduction, Terminology,
Security Considerations, and IANA Considerations.
</t>
<t>
Changed terminology from "embed router" to "edge router".
</t>
<t>
Added text for "Prefix Exchange with the First-hop Infrastructure."
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:24:34 |