--- 1/draft-ietf-ipwave-vehicular-networking-06.txt 2018-11-04 18:14:27.855963209 -0800 +++ 2/draft-ietf-ipwave-vehicular-networking-07.txt 2018-11-04 18:14:27.923964855 -0800 @@ -1,19 +1,19 @@ IPWAVE Working Group J. Jeong, Ed. Internet-Draft Sungkyunkwan University -Intended status: Informational October 22, 2018 -Expires: April 25, 2019 +Intended status: Informational November 4, 2018 +Expires: May 8, 2019 IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases - draft-ietf-ipwave-vehicular-networking-06 + draft-ietf-ipwave-vehicular-networking-07 Abstract This document discusses the problem statement and use cases on IP- based vehicular networks, which are considered a key component of 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 surveys use cases using V2V, V2I, and V2X networking. Second, it analyzes proposed protocols for IP-based @@ -33,21 +33,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 April 25, 2019. + This Internet-Draft will expire on May 8, 2019. Copyright Notice Copyright (c) 2018 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 @@ -58,57 +58,57 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4. Analysis for Existing Protocols . . . . . . . . . . . . . . . 7 + 4. Analysis for Existing Protocols . . . . . . . . . . . . . . . 8 4.1. Existing Protocols for Vehicular Networking . . . . . . . 8 4.1.1. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . 8 4.1.2. IP Address Autoconfiguration . . . . . . . . . . . . 8 4.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.4. Mobility Management . . . . . . . . . . . . . . . . . 9 4.1.5. DNS Naming Service . . . . . . . . . . . . . . . . . 9 4.1.6. Service Discovery . . . . . . . . . . . . . . . . . . 9 4.1.7. Security and Privacy . . . . . . . . . . . . . . . . 10 4.2. General Problems . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Vehicular Network Architecture . . . . . . . . . . . 11 - 4.2.2. Latency . . . . . . . . . . . . . . . . . . . . . . . 15 - 4.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 15 - 4.2.4. Pseudonym Handling . . . . . . . . . . . . . . . . . 15 - 5. Problem Exploration . . . . . . . . . . . . . . . . . . . . . 16 - 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 16 - 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 16 - 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 17 - 5.1.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 17 - 5.1.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 17 - 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 18 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 7. Informative References . . . . . . . . . . . . . . . . . . . 19 - Appendix A. Relevant Topics to IPWAVE Working Group . . . . . . 27 - A.1. Vehicle Identity Management . . . . . . . . . . . . . . . 27 - A.2. Multihop V2X . . . . . . . . . . . . . . . . . . . . . . 27 - A.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 27 - A.4. DNS Naming Services and Service Discovery . . . . . . . . 28 - A.5. IPv6 over Cellular Networks . . . . . . . . . . . . . . . 28 - A.5.1. Cellular V2X (C-V2X) Using 4G-LTE . . . . . . . . . . 28 - A.5.2. Cellular V2X (C-V2X) Using 5G . . . . . . . . . . . . 29 + 4.2.2. Latency . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 16 + 4.2.4. Pseudonym Handling . . . . . . . . . . . . . . . . . 16 + 5. Problem Exploration . . . . . . . . . . . . . . . . . . . . . 17 + 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 17 + 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 17 + 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 18 + 5.1.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 18 + 5.1.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 19 + 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 20 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 7. Informative References . . . . . . . . . . . . . . . . . . . 21 + Appendix A. Relevant Topics to IPWAVE Working Group . . . . . . 29 + A.1. Vehicle Identity Management . . . . . . . . . . . . . . . 29 + A.2. Multihop V2X . . . . . . . . . . . . . . . . . . . . . . 29 + A.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29 + A.4. DNS Naming Services and Service Discovery . . . . . . . . 30 + A.5. IPv6 over Cellular Networks . . . . . . . . . . . . . . . 30 + A.5.1. Cellular V2X (C-V2X) Using 4G-LTE . . . . . . . . . . 30 + A.5.2. Cellular V2X (C-V2X) Using 5G . . . . . . . . . . . . 31 Appendix B. Changes from draft-ietf-ipwave-vehicular- - networking-05 . . . . . . . . . . . . . . . . . . . 29 - Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 29 - Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 29 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 + networking-06 . . . . . . . . . . . . . . . . . . . 31 + Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 31 + Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 32 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction Vehicular networking studies have mainly focused on driving safety, driving efficiency, and entertainment in road networks. The Federal Communications Commission (FCC) in the US allocated wireless channels for Dedicated Short-Range Communications (DSRC) [DSRC], service in the Intelligent Transportation Systems (ITS) Radio Service in the 5.850 - 5.925 GHz band (5.9 GHz band). DSRC-based wireless communications can support vehicle-to-vehicle (V2V), vehicle-to- @@ -187,20 +187,27 @@ Positioning System (GPS)) is included in a vehicle with an OBU for efficient navigation. o Vehicle Detection Loop (or Loop Detector): An inductive device used for detecting vehicles passing or arriving at a certain point, for instance approaching a traffic light or in motorway traffic. The relatively crude nature of the loop's structure means that only metal masses above a certain size are capable of triggering the detection. + o Mobility Anchor (MA): A node that maintains IP addresses and + mobility information of vehicles in a road network to support the + address autoconfiguration and mobility management of them. It has + end-to-end connections with RSUs under its control. It maintains + a DAD table having the IP addresses of the vehicles moving within + the communication coverage of its RSUs. + o Vehicular Cloud: A cloud infrastructure for vehicular networks, having compute nodes, storage nodes, and network nodes. o Traffic Control Center (TCC): A node that maintains road infrastructure information (e.g., RSUs, traffic signals, and loop detectors), vehicular traffic statistics (e.g., average vehicle speed and vehicle inter-arrival time per road segment), and vehicle information (e.g., a vehicle's identifier, position, direction, speed, and trajectory as a navigation path). TCC is included in a vehicular cloud for vehicular networks. @@ -413,82 +421,104 @@ the corresponding IP address in multicast. DNS Name Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming service for Internet-of-Things (IoT) devices in a large-scale network. 4.1.6. Service Discovery To discover instances of a demanded service in vehicular networks, DNS-based Service Discovery (DNS-SD) [RFC6763] with either DNSNA [ID-DNSNA] or mDNS [RFC6762] provides vehicles with service discovery by using standard DNS queries. Vehicular ND [ID-Vehicular-ND] - proposes an extension of IPv6 ND for the prefix and service - discovery. Note that a DNS query for service discovery is unicasted - in DNSNA, but it is multicasted in both mDNS and Vehicular ND. + proposes an extension of IPv6 ND for the prefix and service discovery + with new ND options [ID-VND-Discovery]. Note that a DNS query for + service discovery is unicasted in DNSNA, but it is multicasted in + both mDNS and Vehicular ND. 4.1.7. Security and Privacy For security and privacy, Fernandez et al. proposed a secure vehicular IPv6 communication scheme using Internet Key Exchange version 2 (IKEv2) and Internet Protocol Security (IPsec) [Securing-VCOMM]. Moustafa et al. proposed a security scheme providing authentication, authorization, and accounting (AAA) services in vehicular networks [VNET-AAA]. - *-------------* - * * +-------+ - * Vehicular Cloud *<------>| TCC | - * * +_______+ - *-------------* - ^ ^ - | | - | | - v v - +--------+ Ethernet +--------+ - | RSU1 |<----------->| RSU2 | - +________+ +________+ - ^ ^ ^ - : : : - V2I : : V2I V2I : - v v v - +--------+ +--------+ +--------+ - |Vehicle1|==> |Vehicle2|==> |Vehicle3|==> - | |<....>| |<....>| | - +________+ V2V +________+ V2V +________+ - - <----> Wired Link <....> Wireless Link ==> Moving Direction - - Figure 1: A Vehicular Network Architecture for V2I and V2V Networking - 4.2. General Problems This section describes a possible vehicular network architecture for V2V, V2I, and V2X communications. Then it analyzes the limitations of the current protocols for vehicular networking. + Traffic Control Center in Vehicular Cloud + *-----------------------------------------* + * * + * +----------------+ * + * | Mobility Anchor| * + * +----------------+ * + * ^ * + * | * + *--------------------v--------------------* + ^ ^ ^ + | | | ++------------------ | -------------|-------------+ +------------------+ +| v v | | v | +| +--------+ Ethernet +--------+ | | +--------+ | +| | RSU1 |<----------->| RSU2 |<---------->| RSU3 | | +| +--------+ +--------+ | | +--------+ | +| ^ ^ ^ | | ^ | +| : : : | | : | +| V2I : : V2I V2I : | | V2I : | +| v v v | | v | +| +--------+ +--------+ +--------+ | | +--------+ | +| |Vehicle1|===> |Vehicle2|===> |Vehicle3|===>| | |Vehicle4|===>| +| | |<....>| |<....>| | | | | | | +| +--------+ V2V +--------+ V2V +--------+ | | +--------+ | +| | | | ++-------------------------------------------------+ +------------------+ + Subnet1 Subnet2 + + <----> Wired Link <....> Wireless Link ===> Moving Direction + + Figure 1: A Vehicular Network Architecture for V2I and V2V Networking + 4.2.1. Vehicular Network Architecture Figure 1 shows a possible architecture for V2I and V2V networking in a road network. It is assumed that RSUs as routers and vehicles with OBU have wireless media interfaces (e.g., IEEE 802.11-OCB, LTE Uu and Device-to-Device (D2D) (also known as PC5 [TS-23.285-3GPP]), Bluetooth, and Light Fidelity (Li-Fi)) for V2I and V2V communication. Also, it is assumed that such 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. The two RSUs (RSU1 and RSU2) - are deployed in the road network and are connected to a Vehicular - Cloud through the Internet. TCC is connected to the Vehicular Cloud - and the two vehicles (Vehicle1 and Vehicle2) are wirelessly connected - to RSU1, and the last vehicle (Vehicle3) is wirelessly connected to - RSU2. Vehicle1 can communicate with Vehicle2 via V2V communication, - and Vehicle2 can communicate with Vehicle3 via V2V communication. - Vehicle1 can communicate with Vehicle3 via RSU1 and RSU2 employing - V2I (i.e., V2I2V) communication. + support both V2V and V2I networking. Three RSUs (RSU1, RSU2, and + RSU3) are deployed in the road network and are connected to a + Vehicular Cloud through the Internet. A Traffic Control Center (TCC) + is connected to the Vehicular Cloud for the management of RSUs and + vehicles in the road network. A Mobility Anchor (MA) is located in + the TCC as its key component for the mobility management of vehicles. + Two vehicles (Vehicle1 and Vehicle2) are wirelessly connected to + RSU1, and one vehicle (Vehicle3) is wirelessly connected to RSU2. + The wireless networks of RSU1 and RSU2 belong to a multi-link subnet + (denoted as Subnet1) with the same network prefix. Thus, these three + vehicles are within the same subnet. On the other hand, another + vehicle (Vehicle4) is wireless connected to RSU4, belonging to + another subnet (denoted as Subnet2). That is, the first three + vehicles (i.e., Vehicle1, Vehicle2, and Vehicle3) and the last + vehicle (i.e., Vehicle4) are located in the two different subnets. + Vehicle1 can communicate with Vehicle2 via V2V communication, and + Vehicle2 can communicate with Vehicle3 via V2V communication because + they are within the same subnet along their IPv6 addresses, which are + based on the same prefix. On the other hand, Vehicle3 can + communicate with Vehicle4 via RSU2 and RSU3 employing V2I (i.e., + V2I2V) communication because they are within the two different + subnets along with their IPv6 addresses, which are based on the two + different prefixes. In vehicular networks, unidirectional links exist and must be considered for wireless communications. Also, in the vehicular networks, control plane must be separated from data plane for efficient mobility management and data forwarding using Software- Defined Networking (SDN) [SDN-DMM]. ID/Pseudonym change for privacy requires a lightweight DAD. IP tunneling over the wireless link should be avoided for performance efficiency. The mobility information of a mobile (e.g., vehicle-mounted) device through a GPS receiver in its vehicle, such as trajectory, position, speed, and @@ -560,21 +590,21 @@ network and an RSU's fixed network via V2I communication. As shown in Figure 2, the vehicle's moving network and the RSU's fixed network are self-contained networks having multiple subnets and having an edge router for the communication with another vehicle or RSU. The method of prefix assignment for each subnet inside the vehicle's mobile network and the RSU's fixed network is out of scope for this document. Internetworking between two internal networks via V2I communication requires an exchange of network prefix and other parameters through a prefix discovery mechanism, such as ND-based - prefix discovery [ID-Vehicular-ND]. For the ND-based prefix + prefix discovery [ID-VND-Discovery]. For the ND-based prefix discovery, network prefixs and parameters should be registered into a vehicle's router and an RSU router with an external network interface in advance. The network parameter discovery collects networking information for an IP communication between a vehicle and an RSU or between two neighboring vehicles, such as link layer, MAC layer, and IP layer information. The link layer information includes wireless link layer parameters, such as wireless media (e.g., IEEE 802.11-OCB, LTE Uu and D2D, Bluetooth, and LiFi) and a transmission power level. Note that @@ -589,26 +619,26 @@ have been performed, packets can be transmitted between the vehicle's moving network and the RSU's fixed network. DNS services should be supported to enable name resolution for hosts or servers residing either in the vehicle's moving network or the RSU's fixed network. It is assumed that the DNS names of in-vehicle devices and their service names are registered into a DNS server (i.e., recursive DNS server called RDNSS) in a vehicle or an RSU, as shown in Figure 2. For service discovery, those DNS names and service names can be advertised to neighboring vehicles through either DNS-based service discovery mechanisms [RFC6762][RFC6763][ID-DNSNA] and ND-based - service discovery [ID-Vehicular-ND]. For the ND-based service - discovery, service names should be registered into a vehicle's router - and an RSU router with an external network interface in advance. - Refer to Section 4.1.5 and Section 4.1.6 for detailed information. - For these DNS services, an RDNSS within each internal network of a - vehicle or RSU can be used for the hosts or servers. + service discovery [ID-Vehicular-ND][ID-VND-Discovery]. For the ND- + based service discovery, service names should be registered into a + vehicle's router and an RSU router with an external network interface + in advance. Refer to Section 4.1.5 and Section 4.1.6 for detailed + information. For these DNS services, an RDNSS within each internal + network of a vehicle or RSU can be used for the hosts or servers. Figure 2 shows internetworking between the vehicle's moving network and the RSU's fixed network. There exists an internal network (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server (RDNSS1), the two hosts (Host1 and Host2), and the two routers (Router1 and Router2). There exists another internal network (Fixed Network1) inside RSU1. RSU1 has the DNS Server (RDNSS2), one host (Host3), the two routers (Router3 and Router4), and the collection of servers (Server1 to ServerN) for various services in the road networks, such as the emergency notification and navigation. @@ -723,112 +754,140 @@ Advertisement (NA) interval should be adjusted for high-speed vehicles and vehicle density. As vehicles move faster, the NA interval should decrease for the NA messages to reach the neighboring vehicles promptly. Also, as vehicle density is higher, the NA interval should increase for the NA messages to reduce collision probability with other NA messages. 5.1.1. Link Model IPv6 protocols work under certain assumptions for the link model that - do not necessarily hold in WAVE [IPv6-WAVE]. For instance, some IPv6 - protocols assume symmetry in the connectivity among neighboring - interfaces. However, interference and different levels of - transmission power may cause unidirectional links to appear in a WAVE - link model. + do not necessarily hold in a vehicular wireless link [VIP-WAVE]. For + instance, some IPv6 protocols assume symmetry in the connectivity + among neighboring interfaces. However, interference and different + levels of transmission power may cause unidirectional links to appear + in vehicular wireless links. As a result, a new vehicular link model + is required for the vehicular wireless link. There is a relationship between a link and prefix, besides the different scopes that are expected from the link-local and global types of IPv6 addresses. In an IPv6 link, it is assumed that all interfaces which are configured with the same subnet prefix and with on-link bit set can communicate with each other on an IP link or extended IP links via ND proxy. Note that a subnet prefix can be used by spanning multiple links as a multi-link subnet [RFC6775]. Also, note that IPv6 Stateless Address Autoconfiguration can be performed in the multiple links where each of them is not assigned with a unique subnet prefix, that is, all of them are configured with - the same subnet prefix [RFC4861][RFC4862]. A WAVE link model needs - to consider a multi-hop VANET over a multi-link subnet. Such a VANET - is usually a multi-link subnet consisting of multiple vehicles + the same subnet prefix [RFC4861][RFC4862]. A vehicular link model + needs to consider a multi-hop VANET over a multi-link subnet. Such a + VANET is usually a multi-link subnet consisting of multiple vehicles interconnected by wireless communication range. Such a subnet has a highly dynamic topology over time due to node mobility. - Thus, IPv6 ND should be extended to support the concept of an IPv6 - link corresponding to an IPv6 prefix even in a multi-link subnet + Thus, IPv6 ND should be extended into a Vehicular Neighbor Discovey + (VND) [ID-Vehicular-ND] to support the concept of an IPv6 link + corresponding to an IPv6 prefix even in a multi-link subnet consisting of multiple vehicles and RSUs that are interconnected with - wireless communication range in vehicular networks. + wireless communication range in IP-based vehicular networks. 5.1.2. MAC Address Pseudonym In the ETSI standards, for the sake of security and privacy, an ITS station (e.g., vehicle) can use pseudonyms for its network interface identities (e.g., MAC address) and the corresponding IPv6 addresses [Identity-Management]. Whenever the network interface identifier changes, the IPv6 address based on the network interface identifier should be updated. For the continuity of an end-to-end (E2E) - transport-layer (e.g., TCP, UDP, and SCTP) session, the new IP - addresses of the transport-layer session should be notified to both - the end points and the packets of the session should be forwarded to - their destinations with the changed network interface identifier and - IPv6 address. + transport-layer (e.g., TCP, UDP, and SCTP) session, with a mobility + management scheme (e.g., MIPv6 and PMIPv6), the new IP address for + the transport-layer session should be notified to an appropriate end + point, and the packets of the session should be forwarded to their + destinations with the changed network interface identifier and IPv6 + address. 5.1.3. Prefix Dissemination/Exchange A vehicle and an RSU can have their internal network, as shown in Figure 2 and Figure 3. In this case, nodes in within the internal networks of two vehicular nodes (e.g., vehicle and RSU) want to communicate with each other. For this communication on the wireless link, the network prefix dissemination or exchange is required. It is assumed that a vehicular node has an external network interface - and its internal network. The standard IPv6 ND needs to be extended - for the communication between the internal-network vehicular nodes by + and its internal network. The legacy IPv6 ND [RFC4861] needs to be + extended to a vehicular ND (VND) [ID-Vehicular-ND] for the + communication between the internal-network nodes (e.g., an in-vehicle + device in a vehicle and a server in an RSU) of vehicular nodes by letting each of them know the other side's prefix with a new ND - option [ID-Vehicular-ND]. Thus, this ND extension for routing + option [ID-VND-Discovery]. Thus, this ND extension for routing functionality can reduce control traffic for routing in vehicular - networks. + networks without an additional vehicular ad hoc routing protocol + [VANET-Geo-Routing]. 5.1.4. Routing - For Neighbor Discovery in vehicular networks (called vehicular ND), - Ad Hoc routing is required for either unicast or multicast in the - links in a connected VANET with the same IPv6 prefix [GeoSAC]. Also, - a rapid DAD should be supported to prevent or reduce IPv6 address - conflicts in a multi-link subnet for both V2V and V2I by using a DAD - optimization [RFC6775]. + For multihop V2V communications in a multi-link subnet (as a + connected VANET), a vehicular ad hoc routing protocol (e.g., + geographic routing) may be required to support both unicast and + multicast in the links of the subnet with the same IPv6 prefix + [VANET-Geo-Routing]. Instead of the vehicular ad hoc routing + protocol, Vehicular ND along with a prefix discovery option can be + used to let vehicles exchange their prefixes in a multihop fashion + + [ID-Vehicular-ND][ID-VND-Discovery]. With the exchanged prefixes, + they can compute their routing table (or IPv6 ND's neighbor cache) + for the multi-link subnet with a distance-vector algorithm + [Intro-to-Algorithms]. Also, an efficient, rapid DAD should be + supported to prevent or reduce IPv6 address conflicts in the multi- + link subnet by using a DAD optimization [ID-Vehicular-ND][RFC6775] or + an IPv6 geographic-routing-based address autoconfiguration [GeoSAC]. 5.2. Mobility Management The seamless connectivity and timely data exchange between two end points requires an efficient mobility management including location management and handover. Most of vehicles are equipped with a GPS receiver as part of a dedicated navigation system or a corresponding smartphone App. In the case where the provided location information is precise enough, well-known temporary degradations in precision may occur due to system configuration or the adverse local environment. This precision is improved thanks to assistance by the RSUs or a cellular system with this navigation system. With this GPS navigator, an efficient mobility management is possible by vehicles periodically reporting their current position and trajectory (i.e., - navigation path) to TCC. TCC can predict the future positions of the - vehicles with their mobility information (i.e., the current position, - speed, direction, and trajectory) for location management. + navigation path) to RSUs and a Mobility Anchor (MA) in TCC. The RSUs + and MA can predict the future positions of the vehicles with their + mobility information (i.e., the current position, speed, direction, + and trajectory) for the efficient mobility management (e.g., + proactive handover). For a better proactive handover, link-layer + parameters, such as the signal strength of a link-layer frame (e.g., + Received Channel Power Indicator (RCPI) [VIP-WAVE]), can be used to + determine the moment of a handover between RSUs along with mobility + information [ID-Vehicular-ND]. - With the prediction of the vehicle mobility, TCC can support RSUs to + With the prediction of the vehicle mobility, MA can support RSUs to perform DAD, data packet routing, horizontal handover (i.e., handover in wireless links using a homogeneous radio technology), and vertical handover (i.e., handover in wireless links using heterogeneous radio - technologies) in a proactive manner. When it is assigned a new IPv6 - address belonging to a different subnet, a vehicle can skip the DAD - operation, reducing IPv6 control traffic overhead. RSUs can - efficiently forward data packets from the wired network to a moving - destination vehicle along its trajectory. RSUs can smoothly perform - handover for the sake of a moving vehicle along its trajectory. + technologies) in a proactive manner. Even though a vehicle moves + into the wireless link under another RSU belonging to a different + subnet, the RSU can proactively perform the DAD for the sake of the + vehicle, reducing IPv6 control traffic overhead in the wireless link + [ID-Vehicular-ND]. + + Therefore, with a proactive handover and a multihop DAD in vehicular + networks [ID-Vehicular-ND], RSUs can efficiently forward data packets + from the wired network (or the wireless network) to a moving + destination vehicle along its trajectory along with the MA. Thus, a + moving vehicle can communicate with its corresponding vehicle in the + vehicular network or a host/server in the Internet along its + trajectory. 5.3. Security and Privacy Security and privacy are paramount in the V2I, V2V, and V2X networking in vehicular networks. Only authorized vehicles should be allowed to use vehicular networking. Also, in-vehicle devices and mobile devices in a vehicle need to communicate with other in-vehicle devices and mobile devices in another vehicle, and other servers in an RSU in a secure way. @@ -964,20 +1023,26 @@ Mobile Users", IEEE International Conference on Communications, June 2015. [ID-DNSNA] Jeong, J., Ed., Lee, S., and J. Park, "DNS Name Autoconfiguration for Internet of Things Devices", draft- jeong-ipwave-iot-dns-autoconf-04 (work in progress), October 2018. [ID-Vehicular-ND] + Xiang, Zhong., Jeong, J., Ed., and Y. Shen, "IPv6 Neighbor + Discovery for IP-Based Vehicular Networks", draft-xiang- + ipwave-vehicular-neighbor-discovery-00 (work in progress), + November 2018. + + [ID-VND-Discovery] Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and J. Lee, "IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks", draft-jeong-ipwave-vehicular- neighbor-discovery-04 (work in progress), October 2018. [Identity-Management] Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer Identities Management in ITS Stations", The 10th International Conference on ITS Telecommunications, November 2010. @@ -986,32 +1051,37 @@ IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2016, December 2016. [IEEE-802.11p] IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 6: Wireless Access in Vehicular Environments", IEEE Std 802.11p-2010, June 2010. + [Intro-to-Algorithms] + H. Cormen, T., E. Leiserson, C., L. Rivest, R., and C. + Stein, "Introduction to Algorithms, 3rd ed.", The + MIT Press, July 2009. + [IP-Passing-Protocol] Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol for Vehicular Ad Hoc Networks with Network Fragmentation", Elsevier Computers & Mathematics with Applications, January 2012. [IPv6-over-802.11-OCB] Petrescu, A., Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)", draft-ietf-ipwave- - ipv6-over-80211ocb-25 (work in progress), June 2018. + ipv6-over-80211ocb-30 (work in progress), September 2018. [IPv6-WAVE] Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6 Operation for WAVE - Wireless Access in Vehicular Environments", IEEE Vehicular Networking Conference, December 2010. [ISO-ITS-IPv6] ISO/TC 204, "Intelligent Transport Systems - Communications Access for Land Mobiles (CALM) - IPv6 @@ -1154,21 +1224,21 @@ [VANET-Geo-Routing] Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Goleva, M., and T. Ernst, "Experimental Evaluation for IPv6 over VANET Geographic Routing", IEEE International Wireless Communications and Mobile Computing Conference, June 2010. [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 - Systems, March 2013. + Systems, vol. 14, no. 1, March 2013. [VMaSC-LTE] Ucar, S., Ergen, S., and O. Ozkasap, "Multihop-Cluster- Based IEEE 802.11p and LTE Hybrid Architecture for VANET Safety Message Dissemination", IEEE Transactions on Vehicular Technology, April 2016. [VNET-AAA] Moustafa, H., Bourdon, G., and Y. Gourhant, "Providing Authentication and Access Control in Vehicular Network @@ -1256,21 +1326,21 @@ recursive DNS server (RDNSS) within an internal network can perform such DNS name resolution for the sake of other vehicular nodes. A service discovery service is required for an application in a vehicular node to search for another application or server in another vehicular node, which resides in either the same internal network or the other internal network. In V2I or V2V networking, as shown in Figure 2 and Figure 3, such a service discovery service can be provided by either DNS-based Service Discovery (DNS-SD) [RFC6763] with mDNS [RFC6762] or the vehicular ND with a new option for service - discovery [ID-Vehicular-ND]. + discovery [ID-Vehicular-ND][ID-VND-Discovery]. A.5. IPv6 over Cellular Networks Recently, 3GPP has announced a set of new technical specifications, such as Release 14 (3GPP-R14), which proposes an architecture enhancements for V2X services using the modified sidelink interface that originally is designed for the LTE-D2D communications. 3GPP-R14 specifies that the V2X services only support IPv6 implementation. 3GPP is also investigating and discussing the evolved V2X services in the next generation cellular networks, i.e., 5G new radio (5G-NR), @@ -1298,27 +1368,39 @@ The emerging services, functions, and applications, which are developped in automotive industry, demand reliable and efficient communication infrastructure for road networks. Correspondingly, the support of enhanced V2X (eV2X)-based services by future converged and interoperable 5G systems is required. The 3GPP Technical Report [TR-22.886-3GPP] is studying new use cases and the corresponding service requirements for V2X (including V2V and V2I) using 5G in both infrastructure mode and the sidelink variations in the future. -Appendix B. Changes from draft-ietf-ipwave-vehicular-networking-05 +Appendix B. Changes from draft-ietf-ipwave-vehicular-networking-06 The following changes are made from draft-ietf-ipwave-vehicular- - networking-05: + networking-06: - o In Figure 2 and Figure 3, the vehicle networks and RSU network are - updated. + o In Figure 1, a vehicular network architecture is modified to show + a vehicular link model in a multi-link subnet with vehicular + wireless links. + + o In Section 5.1, a Vehicular Neighbor Discovery (VND) + [ID-Vehicular-ND] is introduced along with a vehicular link model + in a multi-link subnet. In such a subnet, the description of MAC + Address Pseudonym, Prefix Dissemination/Exchange, and Routing is + clarified. + + o In Section 5.2, a proactive handover is introduced for an + efficient mobility management with the cooperation among vehicles, + RSUs, and MA along with link-layer parameters, such as Received + Channel Power Indicator (RCPI). Appendix C. Acknowledgments This work was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (2017R1D1A1B03035885). This work was supported in part by Global Research Laboratory Program through the NRF funded by the Ministry of Science and ICT (MSIT) (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT @@ -1343,24 +1425,24 @@ 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 - Department of Electrical Engineering + NIC Chile Research Labs Universidad de Chile - Av. Tupper 2007, Of. 504 - Santiago, 8370451 + Av. Blanco Encalada 1975 + Santiago Chile Phone: +56 2 29784093 EMail: scespede@niclabs.cl Jerome Haerri Communication Systems Department EURECOM Sophia-Antipolis France