| 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
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 (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.
intro
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
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 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.
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).
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.
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:
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.
The Problem of Prefix Exchange with the First-hop Infrastructure
conclusions
security
iana
contributors
acks
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [I-D.liu-its-scenario] | Liu, D., "Scenario of Intelligent Transportation System", Internet-Draft draft-liu-its-scenario-00, 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", Internet-Draft draft-petrescu-ipv6-over-80211p-02, June 2014. |
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: