idnits 2.17.1 draft-petrescu-its-problem-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2016) is 2821 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.liu-its-scenario' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'I-D.petrescu-ipv6-over-80211p' is defined on line 294, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-petrescu-ipv6-over-80211p-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Petrescu 2 Internet-Draft CEA, LIST 3 Intended status: Informational D. Liu 4 Expires: January 8, 2017 Alibaba 5 C. Perkins 6 Futurewei 7 July 8, 2016 9 Problem Statement for IP in ITS use cases C-ACC and Platooning 10 draft-petrescu-its-problem-03.txt 12 Abstract 14 Two vehicle-to-vehicle communications use cases are discussed, namely 15 Cooperative Adaptive Cruise Control (C-ACC) and Platooning. For 16 these two use cases, the problems are identified that pertain to 17 development with Internet protocols and connectivity. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 21, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Discovery Sub-Problem . . . . . . . . . . . . . . . . . . 5 57 3.2. Prefix Exchange sub-Problem . . . . . . . . . . . . . . . 5 58 3.3. Prefix Exchange with the First-hop Infrastructure . . . . 6 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 6.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 Recent years have seen growing interest in vehicle-to-vehicle 70 communications. C-ACC and Platooning are two use cases that hold 71 promise for major increases in vehicle safety as well as fuel 72 efficiency. In this document we explore the problem of realizing 73 solutions for these use cases using well-known Internet protocols and 74 applications. 76 2. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 This document defines the following terminology: 84 Cooperative Adaptive Cruise Control (C-ACC) 85 The automation of speed maintenance in several cooperating 86 vehicles (increase torque if uphill, smoothly brake downhill, such 87 as to maintain constant speed). The term "Adaptive Cruise 88 Control" was used earlier in related ISO standards. The concept 89 of C-ACC aims at the same level of automation but in a cooperative 90 manner between several vehicles: while in CC mode, when a vehicle 91 in front slowly decelerates, this vehicle will also do, such as to 92 maintain distance, and relieve driver from taking over control. 94 edge router 95 An edge router connects the internal networks of the vehicle to 96 the external world, including road side stations, wide-area 97 Internet connectivity, and the edge routers of other vehicles. 99 Platooning 100 Platooning is a concept related to larger vehicles following each 101 other. The goal in this case is more than just comfort - large 102 gains are expected in terms of gas consumption. When large 103 vehicles can follow each other at small distance the air-drag is 104 much lower, reducing gas consumption, tire use, and more. 106 3. The Problem 108 Several use-cases in Intelligent Transportation Systems (ITS) may be 109 implementable using the TCP/IP suite of protocols and consequently 110 benefit from the global availability of Internet connectivity. 111 Cooperative Adaptive Cruise Control (C-ACC) and Platooning are two 112 such use cases. They both require low-latency data exchanges between 113 vehicles. For these use cases, connecting the vehicles through long- 114 range cellular networks typically incurs too much delay. Instead, it 115 is necessary to connect vehicles directly, by using shorter-range 116 communication technologies. 118 A vehicle embeds several IP devices, forming a stable network. 119 Typically, Ethernet cables are run through a car, together with the 120 CAN networks. Computers in an automobile perform an ever-growing 121 variety of sensing and control tasks. Typically one edge router is 122 in charge of wireless communications outside the car, potentially via 123 multiple technologies. 125 The problem is how best to establish low-latency IP communication 126 paths between the computer on the networks embedded in two or more 127 neighboring and potentially fast-moving vehicles. The C-ACC use-case 128 illustrates this problem. When a vehicle sends its coordinates to 129 the vehicle behind it, the latter vehicle may subsequently act by 130 braking under certain circumstances, which then must trigger 131 immediate responses from the other cooperating vehicles. 133 Vehicle 1 Vehicle 2 134 e.g. 135 o)) LTE D2D ((o 136 | 802.11p | 137 | LiFi | 138 | | 139 +------+ +--+--+ +--+--+ +----------+ 140 |GPS PC| | eR1 | | eR2 | |Braking PC| 141 +--+---+ +--+--+ +--+--+ +-----+----+ 142 | | | | 143 | | | | 144 | Ethernet | | Ethernet | 145 -+-----------------+- ---+--------------+----- 146 2001:db8:1::/40 2001:db8:2::/40 148 Figure 1: Two vehicles with wireless link 150 Figure 1 depicts two vehicles in close range. Their respective edge 151 routers (eR1 and eR2) can exchange data by using a short-range link- 152 layer wireless technology such as LTE D2D, IEEE 802.11p, Bluetooth, 153 LiFi, among others. 155 The Ethernet (egress) interfaces of eR1 and eR2 form a single IP 156 subnet. In the figure, there is only one IP hop (a wireless link) 157 between eR1 and eR2. 159 Within each vehicle there is at least one subnet, but there are 160 potentially several distinct IP subnets in each vehicle. For the 161 case in which there is only one subnet in each vehicle, the IP hop 162 count between one IP device in one vehicle and the IP device in 163 another vehicle is at most 3: 1 IP hop in each vehicle and 1 IP hop 164 between the vehicles. 166 As an application example, the "GPS PC" in one vehicle sends IP 167 datagrams containing its coordinates to the Braking PC in the other 168 vehicle, controling braking. The IP datagrams are sent through the 169 respective edge routers. 171 In order for GPS PC to reach Braking PC it is necessary that the two 172 edge routers have forwarding information about their respective 173 subnets: eR1 must learn that prefix 2001:db8:2::/40 is reachable 174 through eR2, and vice-versa. It is thus necessary that they exchange 175 routing information. Otherwise, the GPS PC and Braking PC can not 176 reach one another. 178 The problem is divided in a discovery sub-problem (how edge routers 179 discover each other) and a prefix exchange sub-problem (how edge 180 routers exchange routing information). 182 3.1. Discovery Sub-Problem 184 Various information needs to be discovered to set up the IP 185 communication between the vehicles. The information that needs to be 186 discovered by an edge router includes link layer, MAC layer and IP 187 layer information. 189 For link layer information, wireless link layer parameters need to be 190 obtained. For example, determining the power level of received 191 wireless frames can be used to determine the distance between two 192 neighboring vehicles. 194 For MAC layer information, the MAC address information of the 195 neighboring edge router needs to be discovered. 197 For IP layer information, in the above figure, eR1 needs to discover 198 the IP address and IP prefix of eR2 and eR2 also needs to discover 199 the IP address and IP prefix of eR1. Other multicast related 200 information may also need to be discovered. 202 Service-related information sometimes is also needed. For example, a 203 vehicle might wish to indicate that it offers video translation or 204 VPN services to headquarters. 206 3.2. Prefix Exchange sub-Problem 208 As mentioned earlier, establishing single-hop forwarding between two 209 neighboring vehicles is part of the overall problem for supporting 210 C-ACC and platooning. 212 There are two modes of operating a V2V topology: 214 o Peer-to-peer operation: one vehicle connects with another vehicle 215 and exchanges information in a peer basis. 217 o master-slave operation: one slave vehicle connects to another 218 vehicle which is considered to master several other slave 219 vehicles. The slave vehicle may request an allocation of 220 prefixes, and then uses the master vehicle as a default router. 221 Master-slave operation is not considered in this document. 223 The peer-to-peer operation of a V2V topology is an important aspect 224 of ITS use cases such as C-ACC and Platooning. This mode of 225 operation allows each vehicle to send and receive application data 226 (coordinates, speed) as IP packets, without the need of assistance 227 from fixed infrastructure. Each vehicle is preconfigured with a 228 unique IPv6 prefix and each computer in a vehicle is identified by a 229 unique IPv6 address. 231 In order for one computer in one vehicle to reach another computer in 232 another vehicle the edge routers in each vehicle have to learn the 233 IPv6 prefix (and/or the IPv6 address) of the other vehicles. A 234 prefix-exchange mechanism is needed, otherwise the IP communication 235 cannot be established. 237 After each vehicle has informed the other vehicles nearby about its 238 prefix, the forwarding tables of each vehicle must be updated to 239 contain the tuple [prefix; IP address] of the other vehicles. The 240 updating has to deal with situations when vehicles leave the network, 241 otherwise numerous ICMP Destination Unreachable messages may cause 242 undesirable interference on the inter-vehicle medium. 244 It is likely that vehicles will join and leave the set of cooperating 245 vehicles for cruise control, and similarly for vehicles in a platoon. 246 Then the neighbor relationships would need to be re-evaluated, and 247 subnet reachability information would also require updates. 249 3.3. Prefix Exchange with the First-hop Infrastructure 251 In order to establish bidirectional communications with the fixed 252 infrastructure, edge routers must have a topologically correct prefix 253 with the first hop router of the chosen access network for the fixed 254 infrastructure. In order for this to happen, the edge router must 255 first discover the access router for the chosen access network. 257 In order to be effective, the discovery and exchange operations need 258 to be completed very quickly in order to serve the needs of fast- 259 moving vehicles. 261 4. Security Considerations 263 As is the case with typical V2V use cases, privacy is a very 264 important consideration. Information identifying the vehicle could 265 very likely be used to get accurate information about the identity of 266 the driver, and thus the identifiers used for the use cases in this 267 document should be randomly assigned for the purposes required 268 without any necessary correspondence to the actual vehicle 269 identification. 271 Other information stored in each vehicle's networks must not be 272 inadvertently disclosed by protocol errors or by misuse of supported 273 applications. 275 5. IANA Considerations 277 There are no IANA actions specified within this document. 279 6. References 281 6.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, 285 DOI 10.17487/RFC2119, March 1997, 286 . 288 6.2. Informative References 290 [I-D.liu-its-scenario] 291 Liu, D., "Scenario of Intelligent Transportation System", 292 draft-liu-its-scenario-00 (work in progress), March 2015. 294 [I-D.petrescu-ipv6-over-80211p] 295 Petrescu, A., Pfister, P., Benamar, N., and T. 296 Leinmueller, "Transmission of IPv6 Packets over IEEE 297 802.11p Networks", draft-petrescu-ipv6-over-80211p-02 298 (work in progress), June 2014. 300 Appendix A. ChangeLog 302 The changes are listed in reverse chronological order, most recent 303 changes appearing at the top of the list. 305 o Added text for Abstract, Introduction, Terminology, Security 306 Considerations, and IANA Considerations. 308 o Changed terminology from "embed router" to "edge router". 310 o Added text for "Prefix Exchange with the First-hop 311 Infrastructure." 313 Authors' Addresses 315 Alexandre Petrescu 316 CEA, LIST 317 CEA Saclay 318 Gif-sur-Yvette , Ile-de-France 91190 319 France 321 Phone: +33169089223 322 Email: Alexandre.Petrescu@cea.fr 323 Dapeng Liu 324 Alibaba 325 Beijing , Beijing 100022 326 China 328 Phone: +86-13911788933 329 Email: max.ldp@alibaba-inc.com 331 Charles E. Perkins 332 Futurewei Inc. 333 2330 Central Expressway 334 Santa Clara, CA 95050 335 USA 337 Phone: +1-408-330-4586 338 Email: charliep@computer.org