IPWAVE Working Group of IETF: Updated Status Report March 2021
The IPWAVE Working Group at IETF focuses on IP wireless access in vehicular environments, working on V2V and V2I use cases. They are currently emphasizing IPv6 over 802.11-OCB networks, with advancements towards higher bandwidth OCB implementations. The group's main work item involves running an IP layer on 802.11-OCB, with considerations for security, privacy, and subnet structure recommendations. Status reports on RFC 8691 implementation and topologies for IPv6 networks in vehicle-to-vehicle and vehicle-to-Internet scenarios are also discussed.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
IPWAVE Working Group of IETF, an updated status report Alexandre PETRESCU, CEA March 2021
Contents What is IPWAVE Working Group Main WG item: IPv6 over 802.11 OCB Additional WG item: Problem Statement and Use Cases Perspectives
IPWAVE Working Group IP Wireless Access in Vehicular Environments (IPWAVE) is a Working Group at the Internet Engineering Task Force (IETF). Works on V2V and V2I use-cases where IP is well-suited as a networking technology . Liaisons with ISO TC 204, SAE, ETSI ITS, IEEE, ITU CITS, ITU-R WP 5A. Group formed in year 2016, after successful Birds-of-a-Feather (BoF) www.ietfjournal.org/intelligent-transportation-systems-and-the-ietf/ Email list, roughly 340 subscribers www.ietf.org/mailman/listinfo/its
Main Work Item: IPv6 over 802.11-OCB IEEE 802.11p is a MAC and PHY layer for vehicular wireless networks: Operates Outside the Context of a BSSID (802.11-OCB). Works at 5.9GHz bands channels with a short 10MHz width. Requires the use of 802.11 QoS Data headers. Higher power levels are allowed (33 dBm, 40 dBm, country-specific). Future evolutions: 802.11bd. Running an IP layer on 802.11-OCB requires the definition of a few parameters: EtherType is 0x86DD Default MTU is 1500 bytes, minimum MTU size is 1280 bytes Priority (TID) is 1, i.e. Background , also known as AC_BK Interface Identifiers are: based on EUI-64, or are Stable or Opaque IIDs; of length 64 bit. Use IPv6-over-Ethernet [RFC2464], and a simple frame translation from 802.3 to 802.11 in order to minimize the code changes. Subnet structure: recommendations on the use of Neighbor Discovery and Mobile IPv6 protocols in vehicular settings. Security considerations, privacy.
Status RFC 8691 Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11 issued in December 2019 Implementation of RFC 8691 is straightforward: Available as a patch to linux kernels (some parts fully integrated in mainline) See an OCB patch for 16mbit/s and less, at e.g. https://github.com/jfpastrana/ath9k_ocb_linux_4.2.8 Not yet available on BSD systems Advancements towards the use of IPv6 with ath10k drivers For a higher bandwidth OCB (more than 16mbit/s for vehicle networks, e.g. 1Gbit/s) See the OCB patch at: https://gitlab.com/hpi-potsdam/osm/g5-on-linux/11p-on-linux/-/tree/ath10k (important note: contrary to github, one can browse that gitlab URL on IPv6 as well, without a need of having IPv4 on the computer)
Topologies for using IPv6 for Vehicle Networks Disconnected from the Internet Scales well very large (more than what ITS-G5 can do on 5 channels) Demonstrated in camera- less and driver-less convoy (platoon) Vehicle-to-Vehicle IP network topology: IPv6 over OCB at 5.9GHz subnet1 IPv6 over OCB at 5.9GHz subnet2 IPv6 over OCB at 5.9GHz subnetn Vehicle Vehicle Vehicle Vehicle-to-Internet IP network topology: Connected to the Internet Offers access to Internet without going to cellular network Works simultaneously with non-IP CAMs or BSMs, on same channels IPv6 over OCB at 5.9GHz subnet Internet Vehicle RSU Other variations
Additional WG item: Problem Statement and Use Cases draft-ietf-ipwave-vehicular-networking-20 publicly accessible Exercise in identifying gaps and open areas, prioritize for potential upcoming work; Analyse address autoconfiguration, routing, mobility management, DNS, service discovery, security and privacy for IP networking in vehicular environments; Describes general problems; Describes IP-related problems; Mentions also the use of IP in cellular networks for vehicular environments. Further improvements following the review from Area Director
Status WG item IPWAVE Problem Statement is back from IESG, and comments are addressed. The Working Group IPWAVE will probably not meet during the typical IETF online meetings (the July meeting of year 2021, initially planned in San Francisco, is highly likely to happen online exclusively; maybe new hybrid meeting formulas might be plannned for November 2021).
Which channel for IPv6 on 802.11-OCB? FCC plan to re-allocate channels in the 5.9GHz band https://docs.fcc.gov/public/attachments/DOC-361339A1.pdf Response from some members of the IPWAVE WG: https://www.fcc.gov/ecfs/filing/10115292918548 On which channel is one allowed to run IPv6 over 802.11-OCB? FCC re-allocation at 5.9GHz gives half of that space to WiFi (any WiFi) and half to C-V2X Requires to move away from DSRC at 5.9GHz in one year time (until end of year 2021) Allows for exceptions at DSRC deployments, but requests to be informed Risks: C-V2X might not work simultaneously with the IEEE MAC and PHY in the same channel from 5895MHz to 5M925MHz only C-V2X is legitimate (but still unlicensed ) Up to 5895MHz the WiFi 7 will eat all the channels nothing left for OCB mode (but still in an unlicensed area). So, again, on which channel can IPv6 run legitimately on 802.11-OCB? maybe there is no solution.
Towards IPv6 on C-V2X, some leads See the list of C-V2X devices on market, https://5gaa.org/wp-content/uploads/2020/11/5GAA_List-of-C-V2X-Devices.pdf (but beware: not visible if you are on an IPv6-only computer) Identify a miniPCI interface that supports mode4 , and see whether there is a linux driver for it Put IPv6 on it There are risks that are similar to those in OCB mode: There are two kinds of 802.11 WiFi cards that support OCB mode in the market: Those who don t use QoSHeaders cheap. Those who use QoS Headers expensive. RFC8691 IPv6-over-OCB requires those who do QoS Headers; mixtures of cards with and without QoS support work ok, so the RFC works ok too. There are many kinds of C-V2X cards that support multiple Modes They seem(?) to be all expensive, independent of the Mode . They seem to not be compatible with the use of OCB modes of IEEE. THE COST! The cost of hardware and the cost of software, open source or not.
