--- 1/draft-ietf-ipwave-vehicular-networking-21.txt 2021-09-02 09:32:56.281815366 -0700 +++ 2/draft-ietf-ipwave-vehicular-networking-22.txt 2021-09-02 09:32:56.385817953 -0700 @@ -1,19 +1,19 @@ IPWAVE Working Group J. Jeong, Ed. Internet-Draft Sungkyunkwan University -Intended status: Informational 30 August 2021 -Expires: 3 March 2022 +Intended status: Informational 2 September 2021 +Expires: 6 March 2022 IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases - draft-ietf-ipwave-vehicular-networking-21 + draft-ietf-ipwave-vehicular-networking-22 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 3 March 2022. + This Internet-Draft will expire on 6 March 2022. Copyright Notice Copyright (c) 2021 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 carefully, as they describe your rights @@ -65,33 +65,33 @@ 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 14 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 15 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 18 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 23 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 25 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 27 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 27 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 - 6.1. Security Threats in Neighbor Discovery . . . . . . . . . 31 + 6.1. Security Threats in Neighbor Discovery . . . . . . . . . 32 6.2. Security Threats in Mobility Management . . . . . . . . . 33 6.3. Other Threats . . . . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 34 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 35 8.2. Informative References . . . . . . . . . . . . . . . . . 39 Appendix A. Support of Multiple Radio Technologies for V2V . . . 44 Appendix B. Support of Multihop V2X Networking . . . . . . . . . 45 - Appendix C. Support of Mobility Management for V2I . . . . . . . 45 - Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 46 - Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 47 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 + Appendix C. Support of Mobility Management for V2I . . . . . . . 46 + Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 47 + Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 48 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49 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), @@ -171,23 +171,24 @@ * Edge Network (EN): It is an access network that has an IP-RSU for wireless communication with other vehicles having an IP-OBU and wired communication with other network devices (e.g., routers, IP- RSUs, ECDs, servers, and MA). It may have a Global Positioning System (GPS) radio receiver for its position recognition and the localization service for the sake of vehicles. * IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a computer situated in a vehicle (e.g., car, bicycle, autobike, motor cycle, and a similar one) and a device (e.g., smartphone and - IoT device). It has at least one IP interface that runs in IEEE - 802.11-OCB and has an "OBU" transceiver. Also, it may have an IP - interface that runs in Cellular V2X (C-V2X) [TS-23.285-3GPP] + Internet-of-Things (IoT) device). It has at least one IP + interface that runs in IEEE 802.11-OCB and has an "OBU" + transceiver. Also, it may have an IP interface that runs in + Cellular V2X (C-V2X) [TS-23.285-3GPP] [TR-22.886-3GPP][TS-23.287-3GPP]. It can play a role of a router connecting multiple computers (or in-vehicle devices) inside a vehicle. See the definition of the term "OBU" in [RFC8691]. * IP-RSU: "IP Roadside Unit": An IP-RSU is situated along the road. It has at least two distinct IP-enabled interfaces. The wireless PHY/MAC layer of at least one of its IP-enabled interfaces is configured to operate in 802.11-OCB mode. An IP-RSU communicates with the IP-OBU over an 802.11 wireless link operating in OCB mode. Also, it may have an IP interface that runs in C-V2X along @@ -1172,53 +1173,53 @@ A routing protocol for a VANET may cause redundant wireless frames in the air to check the neighborhood of each vehicle and compute the routing information in a VANET with a dynamic network topology because the IPv6 ND is used to check the neighborhood of each vehicle. Thus, the vehicular routing needs to take advantage of the IPv6 ND to minimize its control overhead. RPL [RFC6550] defines a routing protocol for low-power and lossy networks, which constructs and maintains DODAGs optimized by an Objective Function (OF). A defined OF provides route selection and - optimization within a RPL topology. A node in a DODAG uses DODAG + optimization within an RPL topology. A node in a DODAG uses DODAG Information Objects (DIOs) messages to discover and maintain the - upward routes toward the root node. + upward routes toward the root node. Refer to Appendix B for the + detailed description of RPL for multihop V2X networking. An address registration extension for 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Network) in [RFC8505] can support light-weight mobility for nodes moving through different parents. Mainly it updates the Address Registration Option (ARO) of ND defined in [RFC6775] to include a status field that can indicate the movement of a node and optionally a Transaction ID (TID) field, i.e., a sequence number that can be used to determine the most recent location of a node. RPL can use the information provided by the extended ARO defined in [RFC8505] to deal with a certain level of node mobility. When a leaf node moves to the coverage of another parent node, it should de- register its addresses to the previous parent node and register itself with a new parent node along with an incremented TID. - Although RPL can be used in IPv6-based vehicular networks, it is - primarily designed for lossy networks, which puts energy efficiency - first. In addition, the topology it considers may not quickly scale - up and down for IPv6-based vehicular networks, since the mobility of - vehicles is much more diverse with a high speed, so it can frequently - alter a tree-like topology formed by RPL, which may cause network - fragmentation and merging with more control traffic. + RPL can be used in IPv6-based vehicular networks, but it is primarily + designed for lossy networks, which puts energy efficiency first. For + using it in IPv6-based vehicular networks, there have not been actual + experiences and practical implementations for vehicular networks, + though it was tested in IoT low-power and lossy networks (LLN) + scenarios. Moreover, due to bandwidth and energy constraints, RPL does not suggest to use a proactive mechanism (e.g., keepalive) to maintain accurate routing adjacencies such as Bidirectional Forwarding Detection [RFC5881] and MANET Neighborhood Discovery Protocol - [RFC6130]. As a result, due to the mobility of vehicles, the network - fragmentation is not detected quickly and the routing of packets + [RFC6130]. As a result, due to the mobility of vehicles, network + fragmentation may not be detected quickly and the routing of packets between vehicles or between a vehicle and an infrastructure node may fail. 5.2. Mobility Management The seamless connectivity and timely data exchange between two end points requires efficient mobility management including location management and handover. Most vehicles are equipped with a GPS receiver as part of a dedicated navigation system or a corresponding smartphone App. Note that the GPS receiver may not provide vehicles @@ -1965,32 +1965,69 @@ Appendix B. Support of Multihop V2X Networking The multihop V2X networking can be supported by RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) [RFC6550] and Overlay Multilink Network Interface (OMNI) [OMNI]. RPL defines an IPv6 routing protocol for low-power and lossy networks (LLN), mostly designed for home automation routing, building automation routing, industrial routing, and urban LLN routing. It uses a destination oriented directed acyclic graph (DODAG) to - construct routing paths for hosts in a network. The DODAG uses an - objective function (OF) for route selection and optimization within - the network. A user can use different routing metrics to define an - OF for a specific scenario. RPL supports multipoint-to-point, point- - to-multipoint, and point-to-point traffic, and the major traffic flow - is the multipoint-to-point traffic. For example, in a highway - scenario, a vehicle may not access an RSU directly because of the - distance of the DSRC coverage (up to 1 km). In this case, the RPL - 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. + construct routing paths for hosts (e.g., IoT devices) in a network. + The DODAG uses an objective function (OF) for route selection and + optimization within the network. A user can use different routing + metrics to define an OF for a specific scenario. RPL supports + multipoint-to-point, point-to-multipoint, and point-to-point traffic, + and the major traffic flow is the multipoint-to-point traffic. For + example, in a highway scenario, a vehicle may not access an RSU + directly because of the distance of the DSRC coverage (up to 1 km). + In this case, the RPL 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. + + RPL is primarily designed to minimize the control plane activity, + which is the relative amount of routing protocol exchanges versus + data traffic; this approach is beneficial for situations where the + power and bandwidth are scarce (e.g., an IoT LLN where RPL is + typically used today), but also in situations of high relative + mobility between the nodes in the network (also known as swarming, + e.g., within a variable set of vehicles with a similar global motion, + or a variable set of drones flying toward the same direction). + + To reduce the routing exchanges, RPL leverages a Distance Vector + approach, which does not need a global knowledge of the topology, and + only optimizes the routes to and from the root, allowing Peer-to-Peer + (P2P) paths to be stretched. Although RPL installs its routes + proactively, it only maintains them lazily, that is, in reaction to + actual traffic, or as a slow background activity. Additionally, RPL + leverages the concept of an objective function (called OF), which + allows to adapt the activity of the routing protocol to use cases, + e.g., type, speed, and quality of the radios. RPL does not need + converge, and provides connectivity to most nodes most of the time. + The default route toward the root is maintained aggressively and may + change while a packet progresses without causing loops, so the packet + will still reach the root. There are two modes for routing in RPL + such as non-storing mode and storing mode. In non-storing mode, a + node inside the mesh/swarm that changes its point(s) of attachment to + the graph informs the root with a single unicast packet flowing along + the default route, and the connectivity is restored immediately; this + mode is preferable for use cases where Internet connectivity is + dominant. On the other hand, in storing mode, the routing stretch is + reduced, for a better P2P connectivity, while the Internet + connectivity is restored more slowly, during the time for the DV + operation to operate hop-by-hop. While an RPL topology can quickly + scale up and down and fits the needs of mobility of vehicles, the + total performance of the system will also depend on how quickly a + node can form an address, join the mesh (including Authentication, + Authorization, and Accounting (AAA)), and manage its global mobility + to become reachable from another node outside the mesh. OMNI defines a protocol for the transmission of IPv6 packets over Overlay Multilink Network Interfaces that are virtual interfaces governing multiple physical network interfaces. OMNI supports multihop V2V communication between vehicles in multiple forwarding hops via intermediate vehicles with OMNI links. It also supports multihop V2I communication between a vehicle and an infrastructure access point by multihop V2V communication. The OMNI interface supports an NBMA link model where multihop V2V and V2I communications use each mobile node's ULAs without need for any DAD or MLD @@ -2079,54 +2116,68 @@ Telekom), Pascal Thubert (Cisco), Carlos Bernardos (UC3M), Russ 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), Peter E. Yee (Akayla), and Erik Kline. 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 + Nabil Benamar - Sandra Cespedes NIC Chile Research Labs Universidad de Chile Av. - Blanco Encalada 1975 Santiago Chile Phone: +56 2 29784093 EMail: + 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, Phone: +56 2 29784093, EMail: scespede@niclabs.cl - Jerome Haerri Communication Systems Department EURECOM Sophia- - Antipolis France Phone: +33 4 93 00 81 34 EMail: - jerome.haerri@eurecom.fr + Jerome Haerri - Dapeng Liu Alibaba Beijing, Beijing 100022 China Phone: +86 - 13911788933 EMail: max.ldp@alibaba-inc.com + Communication Systems Department, EURECOM, Sophia-Antipolis, France, + Phone: +33 4 93 00 81 34, EMail: jerome.haerri@eurecom.fr - Tae (Tom) Oh Department of Information Sciences and Technologies - Rochester Institute of Technology One Lomb Memorial Drive Rochester, - NY 14623-5603 USA Phone: +1 585 475 7642 EMail: Tom.Oh@rit.edu - Charles E. Perkins Futurewei Inc. 2330 Central Expressway Santa - Clara, CA 95050 USA Phone: +1 408 330 4586 EMail: - charliep@computer.org + Dapeng Liu - Alexandre Petrescu CEA, LIST CEA Saclay Gif-sur-Yvette, Ile-de-France - 91190 France Phone: +33169089223 EMail: Alexandre.Petrescu@cea.fr + Alibaba, Beijing, Beijing 100022, China, Phone: +86 13911788933, + EMail: max.ldp@alibaba-inc.com - Yiwen Chris Shen Department of Computer Science & Engineering - Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do - 16419 Republic of Korea Phone: +82 31 299 4106 Fax: +82 31 290 7996 - EMail: chrisshen@skku.edu URI: http://iotlab.skku.edu/people-chris- - shen.php + Tae (Tom) Oh - Michelle Wetterwald FBConsulting 21, Route de Luxembourg - Wasserbillig, Luxembourg L-6633 Luxembourg EMail: - Michelle.Wetterwald@gmail.com + Department of Information Sciences and Technologies, Rochester + Institute of Technology, One Lomb Memorial Drive, Rochester, NY + 14623-5603, USA, Phone: +1 585 475 7642, EMail: Tom.Oh@rit.edu + + Charles E. Perkins + Futurewei Inc., 2330 Central Expressway, Santa Clara, CA 95050, USA, + Phone: +1 408 330 4586, EMail: charliep@computer.org + + Alexandre Petrescu + + CEA, LIST, CEA Saclay, Gif-sur-Yvette, Ile-de-France 91190, France, + Phone: +33169089223, EMail: Alexandre.Petrescu@cea.fr + + Yiwen Chris Shen + + Department of Computer Science & Engineering, Sungkyunkwan + University, 2066 Seobu-Ro, Jangan-Gu, Suwon, Gyeonggi-Do 16419, + Republic of Korea, Phone: +82 31 299 4106, Fax: +82 31 290 7996, + EMail: chrisshen@skku.edu, URI: https://chrisshen.github.io + + Michelle Wetterwald + + FBConsulting, 21, Route de Luxembourg, Wasserbillig, Luxembourg + L-6633, Luxembourg, EMail: Michelle.Wetterwald@gmail.com Author's Address Jaehoon (Paul) Jeong (editor) Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419