--- 1/draft-ietf-ipwave-vehicular-networking-15.txt 2020-07-07 09:13:11.815012289 -0700 +++ 2/draft-ietf-ipwave-vehicular-networking-16.txt 2020-07-07 09:13:11.907014627 -0700 @@ -1,19 +1,19 @@ IPWAVE Working Group J. Jeong, Ed. Internet-Draft Sungkyunkwan University -Intended status: Informational June 29, 2020 -Expires: December 31, 2020 +Intended status: Informational July 7, 2020 +Expires: January 8, 2021 IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases - draft-ietf-ipwave-vehicular-networking-15 + draft-ietf-ipwave-vehicular-networking-16 Abstract This document discusses the problem statement and use cases of IPv6-based vehicular networking for Intelligent Transportation Systems (ITS). The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications. First, this document explains use cases using V2V, V2I, and V2X networking. Next, for IPv6-based vehicular networks, it makes a gap analysis of current @@ -30,21 +30,21 @@ 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 https://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 December 31, 2020. + This Internet-Draft will expire on January 8, 2021. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -54,38 +54,38 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 11 - 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 11 + 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 12 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 16 - 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 18 + 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 19 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 21 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 22 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 24 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 25 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Informative References . . . . . . . . . . . . . . . . . . . 29 Appendix A. Changes from draft-ietf-ipwave-vehicular- - networking-14 . . . . . . . . . . . . . . . . . . . 36 + networking-15 . . . . . . . . . . . . . . . . . . . 36 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 36 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 36 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction Vehicular networking studies have mainly focused on improving safety and efficiency, and also enabling entertainment in vehicular networks. The Federal Communications Commission (FCC) in the US allocated wireless channels for Dedicated Short-Range Communications (DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). DSRC- based wireless communications can support vehicle-to-vehicle (V2V), @@ -113,25 +113,25 @@ and V2X in 5G mobile networks (called 5G V2X) [TS-23.285-3GPP] [TR-22.886-3GPP][TS-23.287-3GPP]. With C-V2X, vehicles can directly communicate with each other without relay nodes (e.g., eNodeB in LTE and gNodeB in 5G). Along with these WAVE standards and C-V2X standards, regardless of a wireless access technology under the IP stack of a vehicle, vehicular networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6 protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6) [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Locator/ - ID Separation Protocol (LISP) [RFC6830], and Asymmetric Extended - Route Optimization (AERO) [RFC6706]). In addition, ISO has approved - a standard specifying the IPv6 network protocols and services to be - used for Communications Access for Land Mobiles (CALM) [ISO-ITS-IPv6] - [ISO-ITS-IPv6-AMD1]. + ID Separation Protocol (LISP) [RFC6830BIS], and Asymmetric Extended + Route Optimization (AERO) [RFC6706BIS]). In addition, ISO has + approved a standard specifying the IPv6 network protocols and + services to be used for Communications Access for Land Mobiles (CALM) + [ISO-ITS-IPv6] [ISO-ITS-IPv6-AMD1]. This document describes use cases and a problem statement about IPv6-based vehicular networking for ITS, which is named IPv6 Wireless Access in Vehicular Environments (IPWAVE). First, it introduces the use cases for using V2V, V2I, and V2X networking in ITS. Next, for IPv6-based vehicular networks, it makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy), and then lists up requirements for the extensions of those IPv6 protocols, which are tailored to IPv6-based vehicular networking. Thus, this document is intended to motivate @@ -305,24 +305,28 @@ 3.1. V2V The use cases of V2V networking discussed in this section include o Context-aware navigation for safe driving and collision avoidance; o Cooperative adaptive cruise control in a roadway; o Platooning in a highway; - o Cooperative environment sensing. + o Cooperative environment sensing; - These four techniques will be important elements for self-driving - vehicles. + o Collision avoidance service of end systems of Urban Air Mobility + (UAM). + + These five techniques will be important elements for autonomous + vehicles, which may be either terrestrial vehicles or UAM end + systems. Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers to drive safely by alerting them to dangerous obstacles and situations. That is, a CASD navigator displays obstacles or neighboring vehicles relevant to possible collisions in real-time through V2V networking. CASD provides vehicles with a class-based automatic safety action plan, which considers three situations, namely, the Line-of-Sight unsafe, Non-Line-of-Sight unsafe, and safe situations. This action plan can be put into action among multiple vehicles using V2V networking. @@ -358,30 +362,41 @@ Through cooperative environment sensing, driver-operated vehicles can use environmental information sensed by driverless vehicles for better interaction with the other vehicles and environment. Vehicles can also share their intended maneuvering information (e.g., lane change, speed change, ramp in-and-out, cut-in, and abrupt braking) with neighboring vehicles. Thus, this information sharing can help the vehicles behave as more efficient traffic flows and minimize unnecessary acceleration and deceleration to achieve the best ride comfort. + A collision avoidance service of UAM end systems in air can be + envisioned as a use case in air vehicular environments. This use + case is similar to the context-aware navigator for terrestrial + vehicles. Through V2V coordination, those UAM end systems (e.g., + drones) can avoid a dangerous situation (e.g., collision) in three- + dimensional space rather than two-dimensional space for terrestrial + vehicles. Also, UAM end systems (e.g., flying car) with only a few + meters off the ground can communicate with terrestrial vehicles with + wireless communication technologies (e.g., DSRC, LTE, and C-V2X). + Thus, V2V means any vehicle to any vehicle, whether the vehicles are + ground-level or not. + To encourage more vehicles to participate in this cooperative environmental sensing, a reward system will be needed. Sensing activities of each vehicle need to be logged in either a central way through a logging server (e.g., TCC) in the vehicular cloud or a distributed way (e.g., blockchain [Bitcoin]) through other vehicles or infrastructure. In the case of a blockchain, each sensing message from a vehicle can be treated as a transaction and the neighboring vehicles can play the role of peers in a consensus method of a - blockchain such as Proof of Work (PoW) and Proof of Stake (PoS) - [Bitcoin][Vehicular-BlockChain]. + blockchain [Bitcoin][Vehicular-BlockChain]. The existing IPv6 protocol does not support wireless single-hop V2V communications as well as wireless multihop V2V communications. Thus, the IPv6 needs to support both single-hop and multihop communications in a wireless medium so that vehicles can communicate with each other by V2V communications to share either an emergency situation or road hazard in a highway. To support applications of these V2V use cases, the functions of IPv6 such as VND and VSP are prerequisites for IPv6-based packet exchange @@ -390,21 +405,23 @@ 3.2. V2I The use cases of V2I networking discussed in this section include o Navigation service; o Energy-efficient speed recommendation service; o Accident notification service; - o Electric vehicle (EV) charging service. + o Electric vehicle (EV) charging service; + + o UAM navigation service with efficient battery charging. A navigation service, for example, the Self-Adaptive Interactive Navigation Tool(SAINT) [SAINT], using V2I networking interacts with a TCC for the large-scale/long-range road traffic optimization and can guide individual vehicles along appropriate navigation paths in real time. The enhanced version of SAINT [SAINTplus] can give fast moving paths to emergency vehicles (e.g., ambulance and fire engine) to let them reach an accident spot while redirecting other vehicles near the accident spot into efficient detour paths. @@ -435,20 +452,31 @@ An EV charging service with V2I can facilitates the efficient battery charging of EVs. In the case where an EV charging station is connected to an IP-RSU, an EV can be guided toward the deck of the EV charging station through a battery charging server connected to the IP-RSU. In addition to this EV charging service, other value-added services (e.g., air firmware/software update and media streaming) can be provided to an EV while it is charging its battery at the EV charging station. + A UAM navigation service with efficient battery charging can make the + battery charging schedule of UAM end systems (e.g., drone) for long- + distance flying [CBDN]. For this battery charging schedule, a UAM + end system can communicate with an infrastructure node (e.g., IP-RSU) + toward a cloud server via V2I communications. This cloud server can + coordinate the battery charging schedules of multiple UAM end systems + for their efficient navigation path, considering flight time from + their current position to a battery charging station, waiting time in + a waiting queue at the station, and battery charging time at the + station. + The existing IPv6 protocol does not support wireless multihop V2I communications in a highway where RSUs are sparsely deployed, so a vehicle can reach the wireless coverage of an RSU through the multihop data forwarding of intermediate vehicles. Thus, IPv6 needs to be extended for multihop V2I communications. To support applications of these V2I use cases, the functions of IPv6 such as VND, VMM, and VSP are prerequisites for IPv6-based packet exchange, transport-layer session continuity, and secure, safe communication between a vehicle and a server in the vehicular cloud. @@ -492,30 +520,20 @@ 4. Vehicular Networks This section describes an example vehicular network architecture supporting V2V, V2I, and V2X communications in vehicular networks. It describes an internal network within a vehicle or an edge network (called EN). It explains not only the internetworking between the internal networks of a vehicle and an EN via wireless links, but also the internetworking between the internal networks of two vehicles via wireless links. -4.1. Vehicular Network Architecture - - Figure 1 shows an example vehicular network architecture for V2I and - V2V in a road network [OMNI-Interface]. The vehicular network - architecture contains vehicles (including IP-OBU), IP-RSUs, Mobility - Anchor, Traffic Control Center, and Vehicular Cloud as components. - Note that the components of the vehicular network architecture can be - mapped to those of an IP-based aeronautical network architecture in - [OMNI-Interface], as shown in Figure 2. - Traffic Control Center in Vehicular Cloud ******************************************* +-------------+ * * |Corresponding| * +-----------------+ * | Node |<->* | Mobility Anchor | * +-------------+ * +-----------------+ * * ^ * * | * * v * ******************************************* @@ -540,20 +558,32 @@ | +--------+ | | +--------+ | | +--------+ | | |Vehicle5|===> | | |Vehicle6|===>| | |Vehicle7|==>| | +--------+ | | +--------+ | | +--------+ | +-----------------+ +-----------------+ +-----------------+ Subnet1 Subnet2 Subnet3 (Prefix1) (Prefix2) (Prefix3) <----> Wired Link <....> Wireless Link ===> Moving Direction Figure 1: An Example Vehicular Network Architecture for V2I and V2V + +4.1. Vehicular Network Architecture + + Figure 1 shows an example vehicular network architecture for V2I and + V2V in a road network [OMNI-Interface]. The vehicular network + architecture contains vehicles (including IP-OBU), IP-RSUs, Mobility + Anchor, Traffic Control Center, and Vehicular Cloud as components. + + Note that the components of the vehicular network architecture can be + mapped to those of an IP-based aeronautical network architecture in + [OMNI-Interface], as shown in Figure 2. + +-------------------+------------------------------------+ | Vehicular Network | Aeronautical Network | +===================+====================================+ | IP-RSU | Access Router (AR) | +-------------------+------------------------------------+ | Vehicle (IP-OBU) | Mobile Node (MN) | +-------------------+------------------------------------+ | Moving Network | End User Network (EUN) | +-------------------+------------------------------------+ | Mobility Anchor | Mobility Service Endpoint (MSE) | @@ -564,30 +594,50 @@ Figure 2: Mapping between Vehicular Network Components and Aeronautical Network Components These components are not mandatory, and they can be deployed into vehicular networks in various ways. Some of them (e.g., Mobility Anchor, Traffic Control Center, and Vehicular Cloud) may not be needed for the vehicular networks according to target use cases in Section 3. An existing network architecture (e.g., an IP-based aeronautical - network architecture [OMNI-Interface], a network architecture of - PMIPv6 [RFC5213], and a low-power and lossy network architecture - [RFC6550]) can be extended to a vehicular network architecture for - multihop V2V, V2I, and V2X, as shown in Figure 1. In a highway - scenario, a vehicle may not access an RSU directly because of the - distance of the DSRC coverage (up to 1 km). For example, RPL (IPv6 - Routing Protocol for Low-Power and Lossy Networks) [RFC6550] can be - extended to support a multihop V2I since a vehicle can take advantage - of other vehicles as relay nodes to reach the RSU. Also, RPL can be - extended to support both multihop V2V and V2X in the similar way. + network architecture [OMNI-Interface][UAM-ITS], a network + architecture of PMIPv6 [RFC5213], and a low-power and lossy network + architecture [RFC6550]) can be extended to a vehicular network + architecture for multihop V2V, V2I, and V2X, as shown in Figure 1. + In a highway scenario, a vehicle may not access an RSU directly + because of the distance of the DSRC coverage (up to 1 km). For + example, RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) + [RFC6550] can be extended to support a multihop V2I since a vehicle + can take advantage of other vehicles as relay nodes to reach the RSU. + Also, RPL can be extended to support both multihop V2V and V2X in the + similar way. + + Wireless communications needs to be considered for end systems for + Urban Air Mobility (UAM) such as flying cars and taxis [UAM-ITS]. + These UAM end systems may have multiple wireless transmission media + interfaces (e.g., cellular, communications satellite (SATCOM), short- + range omni-directional interfaces), which are offered by different + data link service providers. To support not only the mobility + management of the UAM end systems, but also the multihop and + multilink communications of the UAM interfaces, the UAM end systems + can employ an Overlay Multilink Network (OMNI) interface + [OMNI-Interface] as a virtual Non-Broadcast Multiple Access (NBMA) + connection to a serving ground domain infrastructure. This + infrastructure can be configured over the underlying data links. The + OMNI interface and its link model provide a means of multilink, + multihop and mobility coordination to the legacy IPv6 ND messaging + [RFC4861] according to the NBMA principle. Thus, the OMNI link model + can support efficient UAM internetworking services without additional + mobility messaging, and without any modification to the IPv6 ND + messaging services or link model. As shown in this figure, IP-RSUs as routers and vehicles with IP-OBU have wireless media interfaces for VANET. Furthermore, the wireless media interfaces are autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to support both V2V and V2I networking. Note that 2001:DB8::/32 is a documentation prefix [RFC3849] for example prefixes in this document, and also that any routable IPv6 address needs to be routable in a VANET and a vehicular network including IP- RSUs. @@ -722,32 +772,20 @@ A vehicle's internal network often uses Ethernet to interconnect Electronic Control Units (ECUs) in the vehicle. The internal network can support Wi-Fi and Bluetooth to accommodate a driver's and passenger's mobile devices (e.g., smartphone or tablet). The network topology and subnetting depend on each vendor's network configuration for a vehicle and an EN. It is reasonable to consider the interaction between the internal network and an external network within another vehicle or an EN. - As shown in Figure 3, as internal networks, a vehicle's moving - network and an EN's fixed network are self-contained networks having - multiple subnets and having an edge router (e.g., IP-OBU and IP-RSU) - for the communication with another vehicle or another EN. The - internetworking between two internal networks via V2I communication - requires the exchange of the network parameters and the network - prefixes of the internal networks. For the efficiency, the network - prefixes of the internal networks (as a moving network) in a vehicle - need to be delegated and configured automatically. Note that a - moving network's network prefix can be called a Mobile Network Prefix - (MNP) [OMNI-Interface]. - +-----------------+ (*)<........>(*) +----->| Vehicular Cloud | 2001:DB8:1:1::/64 | | | +-----------------+ +------------------------------+ +---------------------------------+ | v | | v v | | +-------+ +-------+ | | +-------+ +-------+ | | | Host1 | |IP-OBU1| | | |IP-RSU1| | Host3 | | | +-------+ +-------+ | | +-------+ +-------+ | | ^ ^ | | ^ ^ | | | | | | | | | @@ -764,20 +802,32 @@ | v v | | v v v | | ---------------------------- | | ------------------------------- | | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | +------------------------------+ +---------------------------------+ Vehicle1 (Moving Network1) EN1 (Fixed Network1) <----> Wired Link <....> Wireless Link (*) Antenna Figure 3: Internetworking between Vehicle and Edge Network + As shown in Figure 3, as internal networks, a vehicle's moving + network and an EN's fixed network are self-contained networks having + multiple subnets and having an edge router (e.g., IP-OBU and IP-RSU) + for the communication with another vehicle or another EN. The + internetworking between two internal networks via V2I communication + requires the exchange of the network parameters and the network + prefixes of the internal networks. For the efficiency, the network + prefixes of the internal networks (as a moving network) in a vehicle + need to be delegated and configured automatically. Note that a + moving network's network prefix can be called a Mobile Network Prefix + (MNP) [OMNI-Interface]. + Figure 3 also shows the internetworking between the vehicle's moving network and the EN's fixed network. There exists an internal network (Moving Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and Host2), and two routers (IP-OBU1 and Router1). There exists another internal network (Fixed Network1) inside EN1. EN1 has one host (Host3), two routers (IP-RSU1 and Router2), and the collection of servers (Server1 to ServerN) for various services in the road networks, such as the emergency notification and navigation. Vehicle1's IP-OBU1 (as a mobile router) and EN1's IP-RSU1 (as a fixed router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for @@ -809,33 +859,20 @@ uniqueness of an IPv6 address, the configuration and control overhead of the DAD of the wireless link interfaces should be minimized to support the V2I and V2X communications of vehicles moving fast along roadways. 4.3. V2V-based Internetworking This section discusses the internetworking between the moving networks of two neighboring vehicles via V2V communication. - Figure 4 shows the internetworking between the moving networks of two - neighboring vehicles. There exists an internal network (Moving - Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and Host2), - and two routers (IP-OBU1 and Router1). There exists another internal - network (Moving Network2) inside Vehicle2. Vehicle2 has two hosts - (Host3 and Host4), and two routers (IP-OBU2 and Router2). Vehicle1's - IP-OBU1 (as a mobile router) and Vehicle2's IP-OBU2 (as a mobile - router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for - V2V networking. Thus, a host (Host1) in Vehicle1 can communicate - with another host (Host3) in Vehicle2 for a vehicular service through - Vehicle1's moving network, a wireless link between IP-OBU1 and IP- - OBU2, and Vehicle2's moving network. - (*)<..........>(*) 2001:DB8:1:1::/64 | | +------------------------------+ +------------------------------+ | v | | v | | +-------+ +-------+ | | +-------+ +-------+ | | | Host1 | |IP-OBU1| | | |IP-OBU2| | Host3 | | | +-------+ +-------+ | | +-------+ +-------+ | | ^ ^ | | ^ ^ | | | | | | | | | | v v | | v v | @@ -851,20 +888,33 @@ | v v | | v v | | ---------------------------- | | ---------------------------- | | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | +------------------------------+ +------------------------------+ Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) <----> Wired Link <....> Wireless Link (*) Antenna Figure 4: Internetworking between Two Vehicles + Figure 4 shows the internetworking between the moving networks of two + neighboring vehicles. There exists an internal network (Moving + Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and Host2), + and two routers (IP-OBU1 and Router1). There exists another internal + network (Moving Network2) inside Vehicle2. Vehicle2 has two hosts + (Host3 and Host4), and two routers (IP-OBU2 and Router2). Vehicle1's + IP-OBU1 (as a mobile router) and Vehicle2's IP-OBU2 (as a mobile + router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for + V2V networking. Thus, a host (Host1) in Vehicle1 can communicate + with another host (Host3) in Vehicle2 for a vehicular service through + Vehicle1's moving network, a wireless link between IP-OBU1 and IP- + OBU2, and Vehicle2's moving network. + As a V2V use case in Section 3.1, Figure 5 shows the linear network topology of platooning vehicles for V2V communications where Vehicle3 is the leading vehicle with a driver, and Vehicle2 and Vehicle1 are the following vehicles without drivers. (*)<..................>(*)<..................>(*) | | | +-----------+ +-----------+ +-----------+ | | | | | | | +-------+ | | +-------+ | | +-------+ | @@ -1212,22 +1262,25 @@ Even though vehicles can be authenticated with valid certificates by an authentication server in the vehicular cloud, the authenticated vehicles may harm other vehicles, so their communication activities need to be logged in either a central way through a logging server (e.g., TCC) in the vehicular cloud or a distributed way (e.g., blockchain [Bitcoin]) along with other vehicles or infrastructure. For the non-repudiation of the harmful activities of malicious nodes, a blockchain technology can be used [Bitcoin]. Each message from a vehicle can be treated as a transaction and the neighboring vehicles - can play the role of peers in a consensus method of a blockchain such - as PoW and PoS [Bitcoin][Vehicular-BlockChain]. + can play the role of peers in a consensus method of a blockchain + [Bitcoin][Vehicular-BlockChain]. For a blockchain's efficient + consensus in vehicular networks having fast moving vehicles, a new + consensus algorithm needs to be developed or an existing consensus + algorithm needs to be enhanced. To identify malicious vehicles among vehicles, an authentication method is required. A Vehicle Identification Number (VIN) and a user certificate (e.g., X.509 certificate [RFC5280]) along with an in- vehicle device's identifier generation can be used to efficiently authenticate a vehicle or its driver (having a user certificate) through a road infrastructure node (e.g., IP-RSU) connected to an authentication server in the vehicular cloud. This authentication can be used to identify the vehicle that will communicate with an infrastructure node or another vehicle. In the case where a vehicle @@ -1317,20 +1370,25 @@ Available: http://www.path.berkeley.edu/research/automated-and- connected-vehicles/cooperative-adaptive-cruise-control, 2017. [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A Framework of Context-Awareness Safety Driving in Vehicular Networks", International Workshop on Device Centric Cloud (DC2), March 2016. + [CBDN] Kim, J., Kim, S., Jeong, J., Kim, H., Park, J., and T. + Kim, "CBDN: Cloud-Based Drone Navigation for Efficient + Battery Charging in Drone Networks", IEEE Transactions on + Intelligent Transportation Systems, November 2019. + [DMM-FPC] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., Moses, D., and C. Perkins, "Protocol for Forwarding Policy Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-13 (work in progress), March 2020. [DSRC] ASTM International, "Standard Specification for Telecommunications and Information Exchange Between Roadside and Vehicle Systems - 5 GHz Band Dedicated Short Range Communications (DSRC) Medium Access Control (MAC) and Physical Layer (PHY) Specifications", @@ -1471,31 +1529,35 @@ 2011. [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. - [RFC6706] Templin, F., "Asymmetric Extended Route Optimization - (AERO)", RFC 6706, August 2012. + [RFC6706BIS] + Templin, F., "Asymmetric Extended Route Optimization + (AERO)", draft-templin-intarea-6706bis-58 (work in + progress), June 2020. [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012. - [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The - Locator/ID Separation Protocol (LISP)", RFC 6830, January - 2013. + [RFC6830BIS] + Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. + Cabellos, "The Locator/ID Separation Protocol (LISP)", + draft-ietf-lisp-rfc6830bis-32 (work in progress), March + 2020. [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014. [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. @@ -1562,20 +1624,24 @@ [TS-23.285-3GPP] 3GPP, "Architecture Enhancements for V2X Services", 3GPP TS 23.285/Version 16.2.0, December 2019. [TS-23.287-3GPP] 3GPP, "Architecture Enhancements for 5G System (5GS) to Support Vehicle-to-Everything (V2X) Services", 3GPP TS 23.287/Version 16.2.0, March 2020. + [UAM-ITS] Templin, F., "Urban Air Mobility Implications for + Intelligent Transportation Systems", draft-templin-ipwave- + uam-its-03 (work in progress), July 2020. + [Vehicular-BlockChain] Dorri, A., Steger, M., Kanhere, S., and R. Jurdak, "BlockChain: A Distributed Solution to Automotive Security and Privacy", IEEE Communications Magazine, Vol. 55, No. 12, December 2017. [VIP-WAVE] Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular Networks", IEEE Transactions on Intelligent Transportation @@ -1595,30 +1661,37 @@ [WAVE-1609.3] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Networking Services", IEEE Std 1609.3-2016, April 2016. [WAVE-1609.4] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Multi-Channel Operation", IEEE Std 1609.4-2016, March 2016. -Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-14 +Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-15 The following changes are made from draft-ietf-ipwave-vehicular- - networking-14: + networking-15: - o This version is revised based on the comments from eight - reviewers: Nancy Cam-Winget (Cisco), Fred L. Templin (The Boeing - Company), Jung-Soo Park (ETRI), Zeungil (Ben) Kim (Hyundai - Motors), Kyoungjae Sun (Soongsil University), Zhiwei Yan (CNNIC), - Yong-Joon Joe (LSware), and Peter E. Yee (Akayla). + o This version is revised based on the further comments from the + following reviewers: Fred L. Templin (The Boeing Company) and + YongJoon Joe (LSware). + + o According to the comments from Fred L. Templin, in Section 3.1 + and Section 3.2, UAM (Urban Air Mobility) end systems are + considered for new V2V and V2I use cases. + + o According to the comments from YongJoon Joe, in Section 3.1 and + Section 6, the text about a consensus method of a blockchain in + vehicular networks is revised such that a consensus algorithm + needs to be efficient for fast moving vehicles. Appendix B. Acknowledgments This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning). This work was supported in part by the MSIT (Ministry of Science and @@ -1632,30 +1705,34 @@ Appendix C. Contributors This document is a group work of IPWAVE working group, greatly benefiting from inputs and texts by Rex Buddenberg (Naval Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest University of Technology and Economics), Jose Santa Lozanoi (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot), Sri Gundavelli (Cisco), Erik Nordmark, Dirk von Hugo (Deutsche Telekom), Pascal Thubert (Cisco), Carlos Bernardos (UC3M), Russ - Housley (Vigil Security), and Suresh Krishnan (Kaloom). The authors - sincerely appreciate their contributions. + Housley (Vigil Security), Suresh Krishnan (Kaloom), Nancy Cam-Winget + (Cisco), Fred L. Templin (The Boeing Company), Jung-Soo Park (ETRI), + Zeungil (Ben) Kim (Hyundai Motors), Kyoungjae Sun (Soongsil + University), Zhiwei Yan (CNNIC), YongJoon Joe (LSware), and Peter E. + Yee (Akayla). The authors sincerely appreciate their contributions. The following are co-authors of this document: Nabil Benamar Department of Computer Sciences High School of Technology of Meknes Moulay Ismail University Morocco + Phone: +212 6 70 83 22 36 EMail: benamar73@gmail.com Sandra Cespedes NIC Chile Research Labs Universidad de Chile Av. Blanco Encalada 1975 Santiago Chile