[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]
Versions: 00 01 02 03
Network Working Group A. Petrescu
Internet-Draft CEA, LIST
Intended status: Informational D. Liu
Expires: March 21, 2016 September 18, 2015
Problem Statement for the use of IP in some ITS scenarios
draft-petrescu-its-problem-00.txt
Abstract
abstract
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 March 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Petrescu & Liu Expires March 21, 2016 [Page 1]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Discovery sub-Problem . . . . . . . . . . . . . . . . . . . . 4
5. Prefix Exchange sub-Problem . . . . . . . . . . . . . . . . . 4
6. Problem of Prefix Exchange with the First-hop
Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 5
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
12.1. Normative References . . . . . . . . . . . . . . . . . . 6
12.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
intro
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].
term
3. The Problem
The problem is how to establish IP communication paths between the
computers embarked in two or more neighboring vehicles.
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.
A vehicle embarks several IP devices, forming a stable embedded
network. Typically Ethernet cables are run through a car, together
Petrescu & Liu Expires March 21, 2016 [Page 2]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015
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.
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.
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
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.
The egress interfaces of eR1, eR2 and eRn form a single IP subnet.
There is only one IP hop between eR1 and eR2.
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.
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.
Petrescu & Liu Expires March 21, 2016 [Page 3]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015
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.
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).
4. 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 the eR includes both link layer, MAC layer and IP layer
information.
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.
For MAC layer information, the MAC address information of the eR need
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. The multicast related
information may also need to be discovered.
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.
5. Prefix Exchange sub-Problem
As mentioned earlier, there is a problem in establishing single-hop
forwarding between two neighboring vehicles.
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 equipotential basis.
o 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
Petrescu & Liu Expires March 21, 2016 [Page 4]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015
default router. This mode of operation is not considered in this
document.
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.
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.
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.
The problem is thus how to realize this prefix exchange.
6. Problem of Prefix Exchange with the First-hop Infrastructure
The Problem of Prefix Exchange with the First-hop Infrastructure
7. Conclusions
conclusions
8. Security Considerations
security
9. IANA Considerations
iana
10. Contributors
contributors
Petrescu & Liu Expires March 21, 2016 [Page 5]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015
11. Acknowledgements
acks
12. References
12.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>.
12.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.
From nil to draft-petrescu-its-problem-00.xml:
o initial version
Authors' Addresses
Alexandre Petrescu
CEA, LIST
CEA Saclay
Gif-sur-Yvette , Ile-de-France 91190
France
Phone: +33169089223
Email: Alexandre.Petrescu@cea.fr
Petrescu & Liu Expires March 21, 2016 [Page 6]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015
Dapeng Liu
Beijing , Beijing 100022
China
Phone: +86-13911788933
Email: maxpassion@gmail.com
Petrescu & Liu Expires March 21, 2016 [Page 7]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/