One document matched: draft-petrescu-its-problem-00.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-00.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="Problem Statement for IP in C-ACC and Platooning">
Problem Statement for the use of IP in some ITS scenarios
</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>
</organization>
<address>
<postal>
<street>
</street>
<city>
Beijing
</city>
<region>
Beijing
</region>
<code>
100022
</code>
<country>
China
</country>
</postal>
<phone>
+86-13911788933
</phone>
<email>
maxpassion@gmail.com
</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>
abstract
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
intro
</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>
term
</t>
</section>
<section anchor="problem"
title="The Problem">
<t>
The problem is how to establish IP communication paths between
the computers embarked in two or more neighboring vehicles.
</t>
<t>
Several use-cases in Intelligent Transportation Systems may
involve the TCP/IP suite of protocols and benefit from
Internet-style interactions. Some applications require
low-latency data exchanges between vehicles: Cooperative
Adaptive Cruise Control, Platooning. For these applications,
connecting the vehicles through long-range cellular networks
brings too high latency. It is necessary to connect vehicles
directly, by using shorter-range communication technologies.
</t>
<t>
A vehicle embarks several IP devices, forming a stable
embedded network. Typically Ethernet cables are run through a
car, together with the CAN networks. More and more computers
in an automobile perform sensing and control tasks. Typically
one embedded Router is in charge of wireless communications
outside the car, potentially via multiple technologies.
</t>
<t>
The problem is how to establish IP communication paths between
the computers embarked in two or more neighboring vehicles.
An instantiation of this problem is with the C-ACC use-case: a
vehicle sends its coordinates to the vehicle behind it; this
latter vehicle subsequently acts on braking, under certain
circumstances.
</t>
<t>
<figure align="center">
<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>
The illustration above depicts two vehicles in close range.
Their respective embedded Routers can exchange data by using a
short-range link-layer wireless technology such as LTE D2D,
IEEE 802.11p, and others.
</t>
<t>
The egress interfaces of eR1, eR2 and eRn form a single IP
subnet. There is only one IP hop between eR1 and eR2.
</t>
<t>
Within each vehicle there is at least one subnet, and there
are potentially several distinct IP subnets in each vehicle.
In case there is one subnet in each vehicle, the IP hop count
between one IP device in one vehicle and the IP device in
another vehicle is maximum 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 embedded Routers.
</t>
<t>
In order for GPS PC to reach Braking PC it is necessary that
the two embedded 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 eRs
discover each other) and a prefix exchange sub-problem (how
eRs exchange routing information).
</t>
</section>
<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 the eR includes both link layer, MAC layer
and IP layer information.
</t>
<t>
For link layer information, the wireless link layer parameters
need to be obtained. For example, power of emmission information
which can be used to determine the distance of the vehicles.
</t>
<t>
For MAC layer information, the MAC address information of the
eR need 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. The
multicast related information may also need to be discovered.
</t>
<t>
Service related information sometimes is also needed. For
example, the eR on the vehicle need to indicate that it
wants to discover other eR on other vehicles that can provides
V2V communications.
</t>
</section>
<section title="Prefix Exchange sub-Problem">
<t>
As mentioned earlier, there is a problem in establishing
single-hop forwarding between two neighboring vehicles.
</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
equipotential basis.
</t>
<t>
client-server operation: one vehicle connects to another
vehicle which is considered to master several other
vehicles. The former may request an allocation of
prefixes, and may use the latter as a default router.
This mode of operation is not considered in this
document.
</t>
</list>
The peer-to-peer operation of a V2V topology is an important
part in ITS applications such as C-ACC and Platooning. This
operation mode 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 pre-equipped 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 it is necessary that the
embedded routers in each vehicle learn the IPv6 prefix
(and/or the IPv6 address) of the other vehicles. A
prefix-exchange mechanism is needed, otherwise the IP
communication can not 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 each
other vehicles. The updating must deal with situations when
vehicles leave the network, otherwise numerous ICMP
Destination Unreachable messages may occur on the
inter-vehicle media.
</t>
<t>
The problem is thus how to realize this prefix exchange.
</t>
</section>
<section title="Problem of Prefix Exchange with the First-hop
Infrastructure">
<t>
The Problem of Prefix Exchange with the First-hop
Infrastructure
</t>
</section>
<section title="Conclusions">
<t>
conclusions
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
security
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
iana
</t>
</section>
<section anchor="Contributors"
title="Contributors">
<t>
contributors
</t>
</section>
<section anchor="Acknowledgements"
title="Acknowledgements">
<t>
acks
</t>
</section>
</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>
From nil to draft-petrescu-its-problem-00.xml:
<list style='symbols'>
<t>
initial version
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:27:33 |