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