draft-ietf-ipwave-vehicular-networking-13.txt   draft-ietf-ipwave-vehicular-networking-14.txt 
IPWAVE Working Group J. Jeong, Ed. IPWAVE Working Group J. Jeong, Ed.
Internet-Draft Sungkyunkwan University Internet-Draft Sungkyunkwan University
Intended status: Informational January 6, 2020 Intended status: Informational March 9, 2020
Expires: July 9, 2020 Expires: September 10, 2020
IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem
Statement and Use Cases Statement and Use Cases
draft-ietf-ipwave-vehicular-networking-13 draft-ietf-ipwave-vehicular-networking-14
Abstract Abstract
This document discusses the problem statement and use cases of This document discusses the problem statement and use cases of
IPv6-based vehicular networking for Intelligent Transportation IPv6-based vehicular networking for Intelligent Transportation
Systems (ITS). The main scenarios of vehicular communications are Systems (ITS). The main scenarios of vehicular communications are
vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and
vehicle-to-everything (V2X) communications. First, this document vehicle-to-everything (V2X) communications. First, this document
explains use cases using V2V, V2I, and V2X networking. Next, it explains use cases using V2V, V2I, and V2X networking. Next, it
makes a problem statement about key aspects in IPv6-based vehicular makes a problem statement about key aspects in IPv6-based vehicular
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 9, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 9 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 11
4.1. Vehicular Network Architecture . . . . . . . . . . . . . 10 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 11
4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 13 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 14
4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 15 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 16
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 16 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 16 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 17
5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 18 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 19
5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 19 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 20
5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 20 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. Informative References . . . . . . . . . . . . . . . . . . . 23 7. Informative References . . . . . . . . . . . . . . . . . . . 24
Appendix A. Changes from draft-ietf-ipwave-vehicular- Appendix A. Changes from draft-ietf-ipwave-vehicular-
networking-12 . . . . . . . . . . . . . . . . . . . 29 networking-13 . . . . . . . . . . . . . . . . . . . 29
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 29 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 29
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 29 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Vehicular networking studies have mainly focused on improving safety Vehicular networking studies have mainly focused on improving safety
and efficiency, and also enabling entertainment in vehicular and efficiency, and also enabling entertainment in vehicular
networks. The Federal Communications Commission (FCC) in the US networks. The Federal Communications Commission (FCC) in the US
allocated wireless channels for Dedicated Short-Range Communications allocated wireless channels for Dedicated Short-Range Communications
(DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with (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- the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). DSRC-
skipping to change at page 4, line 5 skipping to change at page 3, line 52
classifying the surrounding vehicles into different groups for classifying the surrounding vehicles into different groups for
safety purposes according to the geometrical relationship among safety purposes according to the geometrical relationship among
them. The vehicle groups can be classified as Line-of-Sight them. The vehicle groups can be classified as Line-of-Sight
Unsafe, Non-Line-of-Sight Unsafe, and Safe groups [CASD]. Unsafe, Non-Line-of-Sight Unsafe, and Safe groups [CASD].
o Context-Awareness: A vehicle can be aware of spatial-temporal o Context-Awareness: A vehicle can be aware of spatial-temporal
mobility information (e.g., position, speed, direction, and mobility information (e.g., position, speed, direction, and
acceleration/deceleration) of surrounding vehicles for both safety acceleration/deceleration) of surrounding vehicles for both safety
and non-safety uses through sensing or communication [CASD]. and non-safety uses through sensing or communication [CASD].
o DMM: "Distributed Mobility Management" [RFC7333][RFC7429].
o Edge Computing (EC): It is the local computing near an access o Edge Computing (EC): It is the local computing near an access
network (i.e., edge network) for the sake of vehicles and network (i.e., edge network) for the sake of vehicles and
pedestrians. pedestrians.
o Edge Computing Device (ECD): It is a computing device (or server) o Edge Computing Device (ECD): It is a computing device (or server)
for edge computing for the sake of vehicles and pedestrians. for edge computing for the sake of vehicles and pedestrians.
o Edge Network (EN): In is an access network that has an IP-RSU for o Edge Network (EN): In is an access network that has an IP-RSU for
wireless communication with other vehicles having an IP-OBU and wireless communication with other vehicles having an IP-OBU and
wired communication with other network devices (e.g., routers, IP- wired communication with other network devices (e.g., routers, IP-
skipping to change at page 4, line 44 skipping to change at page 4, line 44
Termination Point (WTP), defined in [RFC5415]. See the definition Termination Point (WTP), defined in [RFC5415]. See the definition
of the term "RSU" in [RFC8691]. of the term "RSU" in [RFC8691].
o LiDAR: "Light Detection and Ranging". It is a scanning device to o LiDAR: "Light Detection and Ranging". It is a scanning device to
measure a distance to an object by emitting pulsed laser light and measure a distance to an object by emitting pulsed laser light and
measuring the reflected pulsed light. measuring the reflected pulsed light.
o Mobility Anchor (MA): A node that maintains IPv6 addresses and o Mobility Anchor (MA): A node that maintains IPv6 addresses and
mobility information of vehicles in a road network to support mobility information of vehicles in a road network to support
their IPv6 address autoconfiguration and mobility management with their IPv6 address autoconfiguration and mobility management with
a binding table. An MA has End-to-End (E2E) connections with IP- a binding table. An MA has End-to-End (E2E) connections (e.g.,
RSUs under its control for the address autoconfiguration and tunnels) with IP-RSUs under its control for the address
mobility management of the vehicles. This MA can play a role of a autoconfiguration and mobility management of the vehicles. This
Local Mobility Anchor (LMA) in PMIPv6 [RFC5213] for vehicles MA is similar to a Local Mobility Anchor (LMA) in PMIPv6 [RFC5213]
moving in the road network . for network-based mobility management.
o OCB: "Outside the Context of a Basic Service Set - BSS". It is a o OCB: "Outside the Context of a Basic Service Set - BSS". It is a
mode of operation in which a Station (STA) is not a member of a mode of operation in which a Station (STA) is not a member of a
BSS and does not utilize IEEE Std 802.11 authentication, BSS and does not utilize IEEE Std 802.11 authentication,
association, or data confidentiality [IEEE-802.11-OCB]. association, or data confidentiality [IEEE-802.11-OCB].
o 802.11-OCB: It refers to the mode specified in IEEE Std o 802.11-OCB: It refers to the mode specified in IEEE Std
802.11-2016 [IEEE-802.11-OCB] when the MIB attribute 802.11-2016 [IEEE-802.11-OCB] when the MIB attribute
dot11OCBActivited is 'true'. dot11OCBActivited is 'true'.
skipping to change at page 6, line 46 skipping to change at page 6, line 46
networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to-
Device (V2D). Device (V2D).
Since IP is widely used among various computing devices in the Since IP is widely used among various computing devices in the
Internet, it is expected that the use cases in this section need to Internet, it is expected that the use cases in this section need to
work on top of IPv6 as the network layer protocol. Thus, the IPv6 work on top of IPv6 as the network layer protocol. Thus, the IPv6
for these use cases should be extended for vehicular IPv6 such that for these use cases should be extended for vehicular IPv6 such that
the IPv6 can support the functions of the network layer protocol such the IPv6 can support the functions of the network layer protocol such
as Vehicular Neighbor Discovery (VND), Vehicular Mobility Management as Vehicular Neighbor Discovery (VND), Vehicular Mobility Management
(VMM), and Vehicular Security and Privacy (VSP) in vehicular (VMM), and Vehicular Security and Privacy (VSP) in vehicular
networks. Refer to Section 5 for the problem statement of the networks. Note that the adjective "Vehicular" in this document is
requirements of the vehicular IPv6. used to represent extensions of existing protocols such as IPv6
Neighbor Discovery, IPv6 Mobility Management (e.g., PMIPv6 [RFC5213]
and DMM [RFC7429]), and IPv6 Security and Privacy Mechanisms rather
than new "vehicular-specific" functions. Refer to Section 5 for the
problem statement of the requirements of the vehicular IPv6.
3.1. V2V 3.1. V2V
The use cases of V2V networking discussed in this section include The use cases of V2V networking discussed in this section include
o Context-aware navigation for driving safety and collision o Context-aware navigation for driving safety and collision
avoidance; avoidance;
o Cooperative adaptive cruise control in an urban roadway; o Cooperative adaptive cruise control in an urban roadway;
o Platooning in a highway; o Platooning in a highway;
o Cooperative environment sensing. o Cooperative environment sensing.
These four techniques will be important elements for self-driving These four techniques will be important elements for self-driving
vehicles. vehicles.
The existing IPv6 protocol does not support wireless single-hop V2V
communications as well as wireless multi-hop V2V communications.
Thus, the IPv6 needs to be extended for both single-hop V2V
communications and multi-hop V2V communications.
Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers
to drive safely by alerting the drivers about dangerous obstacles and to drive safely by alerting the drivers about dangerous obstacles and
situations. That is, CASD navigator displays obstacles or situations. That is, CASD navigator displays obstacles or
neighboring vehicles relevant to possible collisions in real-time neighboring vehicles relevant to possible collisions in real-time
through V2V networking. CASD provides vehicles with a class-based through V2V networking. CASD provides vehicles with a class-based
automatic safety action plan, which considers three situations, automatic safety action plan, which considers three situations,
namely, the Line-of-Sight unsafe, Non-Line-of-Sight unsafe, and safe namely, the Line-of-Sight unsafe, Non-Line-of-Sight unsafe, and safe
situations. This action plan can be put into action among multiple situations. This action plan can be put into action among multiple
vehicles using V2V networking. vehicles using V2V networking.
skipping to change at page 8, line 25 skipping to change at page 8, line 32
3.2. V2I 3.2. V2I
The use cases of V2I networking discussed in this section include The use cases of V2I networking discussed in this section include
o Navigation service; o Navigation service;
o Energy-efficient speed recommendation service; o Energy-efficient speed recommendation service;
o Accident notification service. o Accident notification service.
The existing IPv6 protocol does not support wireless multi-hop V2I
communications in a highway where RSUs are sparsely deployed, so a
vehicle can reach the wireless coverage of an RSU through the multi-
hop data forwarding of intermediate vehicles. Thus, the IPv6 needs
to be extended for multi-hop V2I communications.
A navigation service, for example, the Self-Adaptive Interactive A navigation service, for example, the Self-Adaptive Interactive
Navigation Tool (SAINT) [SAINT], using V2I networking interacts with Navigation Tool (SAINT) [SAINT], using V2I networking interacts with
TCC for the large-scale/long-range road traffic optimization and can TCC for the large-scale/long-range road traffic optimization and can
guide individual vehicles for appropriate navigation paths in real guide individual vehicles for appropriate navigation paths in real
time. The enhanced version of SAINT [SAINTplus] can give fast moving time. The enhanced version of SAINT [SAINTplus] can give fast moving
paths to emergency vehicles (e.g., ambulance and fire engine) to let paths to emergency vehicles (e.g., ambulance and fire engine) to let
them reach an accident spot while redirecting other vehicles near the them reach an accident spot while redirecting other vehicles near the
accident spot into efficient detour paths. accident spot into efficient detour paths.
A TCC can recommend an energy-efficient speed to a vehicle that A TCC can recommend an energy-efficient speed to a vehicle that
skipping to change at page 9, line 16 skipping to change at page 9, line 27
IPv6 such as VND, VMM, and VSP are prerequisite for the IPv6-based IPv6 such as VND, VMM, and VSP are prerequisite for the IPv6-based
packet exchange, the transport-layer session continuity, and the packet exchange, the transport-layer session continuity, and the
secure, safe communication between a vehicle and a server in the secure, safe communication between a vehicle and a server in the
vehicular cloud. vehicular cloud.
3.3. V2X 3.3. V2X
The use case of V2X networking discussed in this section is The use case of V2X networking discussed in this section is
pedestrian protection service. pedestrian protection service.
The existing IPv6 protocol does not support wireless multi-hop V2X
(or V2I2X) communications in an urban road network where RSUs are
deployed at intersections, so a vehicle (or a pedestrian's
smartphone) can reach the wireless coverage of an RSU through the
multi-hop data forwarding of intermediate vehicles (or pedestrians'
smartphones). Thus, the IPv6 needs to be extended for multi-hop V2X
(or V2I2X) communications.
A pedestrian protection service, such as Safety-Aware Navigation A pedestrian protection service, such as Safety-Aware Navigation
Application (SANA) [SANA], using V2I2P networking can reduce the Application (SANA) [SANA], using V2I2P networking can reduce the
collision of a vehicle and a pedestrian carrying a smartphone collision of a vehicle and a pedestrian carrying a smartphone
equipped with a network device for wireless communication (e.g., equipped with a network device for wireless communication (e.g.,
WiFi) with an IP-RSU. Vehicles and pedestrians can also communicate WiFi) with an IP-RSU. Vehicles and pedestrians can also communicate
with each other via an IP-RSU. An edge computing device behind the with each other via an IP-RSU. An edge computing device behind the
IP-RSU can collect the mobility information from vehicles and IP-RSU can collect the mobility information from vehicles and
pedestrians, compute wireless communication scheduling for the sake pedestrians, compute wireless communication scheduling for the sake
of them. This scheduling can save the battery of each pedestrian's of them. This scheduling can save the battery of each pedestrian's
smartphone by allowing it to work in sleeping mode before the smartphone by allowing it to work in sleeping mode before the
skipping to change at page 9, line 39 skipping to change at page 10, line 11
with a pedestrian's smartphone by V2X without IP-RSU relaying. with a pedestrian's smartphone by V2X without IP-RSU relaying.
Light-weight mobile nodes such as bicycles may also communicate Light-weight mobile nodes such as bicycles may also communicate
directly with a vehicle for collision avoidance using V2V. directly with a vehicle for collision avoidance using V2V.
To support the applications of these V2X use cases, the functions of To support the applications of these V2X use cases, the functions of
IPv6 such as VND, VMM, and VSP are prerequisite for the IPv6-based IPv6 such as VND, VMM, and VSP are prerequisite for the IPv6-based
packet exchange, the transport-layer session continuity, and the packet exchange, the transport-layer session continuity, and the
secure, safe communication between a vehicle and a pedestrian either secure, safe communication between a vehicle and a pedestrian either
directly or indirectly via an IP-RSU. directly or indirectly via an IP-RSU.
4. Vehicular Networks
This section describes an exemplary 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.
Traffic Control Center in Vehicular Cloud Traffic Control Center in Vehicular Cloud
******************************************* *******************************************
+-------------+ * * +-------------+ * *
|Corresponding| * +-----------------+ * |Corresponding| * +-----------------+ *
| Node |<->* | Mobility Anchor | * | Node |<->* | Mobility Anchor | *
+-------------+ * +-----------------+ * +-------------+ * +-----------------+ *
* ^ * * ^ *
* | * * | *
* v * * v *
******************************************* *******************************************
skipping to change at page 10, line 44 skipping to change at page 11, line 5
| |Vehicle5|===> | | |Vehicle6|===>| | |Vehicle7|==>| | |Vehicle5|===> | | |Vehicle6|===>| | |Vehicle7|==>|
| +--------+ | | +--------+ | | +--------+ | | +--------+ | | +--------+ | | +--------+ |
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
Subnet1 Subnet2 Subnet3 Subnet1 Subnet2 Subnet3
(Prefix1) (Prefix2) (Prefix3) (Prefix1) (Prefix2) (Prefix3)
<----> Wired Link <....> Wireless Link ===> Moving Direction <----> Wired Link <....> Wireless Link ===> Moving Direction
Figure 1: An Exemplary Vehicular Network Architecture for V2I and V2V Figure 1: An Exemplary Vehicular Network Architecture for V2I and V2V
4. Vehicular Networks
This section describes an exemplary 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 4.1. Vehicular Network Architecture
Figure 1 shows an exemplary vehicular network architecture for V2I Figure 1 shows an exemplary vehicular network architecture for V2I
and V2V in a road network. The vehicular network architecture and V2V in a road network. The vehicular network architecture
contains vehicles, IP-RSUs, Vehicular Cloud, Traffic Control Center, contains vehicles, IP-RSUs, Vehicular Cloud, Traffic Control Center,
and Mobility Anchor as components. However, some components in the and Mobility Anchor as components. However, some components in the
vehicular network architecture may not be needed for vehicular vehicular network architecture may not be needed for vehicular
networks, such as Vehicular Cloud, Traffic Control Center, and networks, such as Vehicular Cloud, Traffic Control Center, and
Mobility Anchor. Mobility Anchor.
The existing, well-known architecture such as PMIPv6 [RFC5213] can be
extended to a vehicular network architecture (as shown in Figure 1)
such that it can support wireless multi-hop V2I, multi-hop V2V, and
multi-hop V2X (or V2I2X).
As shown in this figure, IP-RSUs as routers and vehicles with IP-OBU As shown in this figure, IP-RSUs as routers and vehicles with IP-OBU
have wireless media interfaces for VANET. Furthermore, the wireless have wireless media interfaces for VANET. Furthermore, the wireless
media interfaces are autoconfigured with a global IPv6 prefix (e.g., 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:1:1::/64) to support both V2V and V2I networking. Note that
2001:DB8::/32 is a documentation prefix [RFC3849] for example 2001:DB8::/32 is a documentation prefix [RFC3849] for example
prefixes in this document, and also that any routable IPv6 address prefixes in this document, and also that any routable IPv6 address
needs to be routable in a VANET and a vehicular network including IP- needs to be routable in a VANET and a vehicular network including IP-
RSUs. RSUs.
For IPv6 packets transported over IEEE 802.11-OCB, [RFC8691] For IPv6 packets transported over IEEE 802.11-OCB, [RFC8691]
skipping to change at page 11, line 38 skipping to change at page 12, line 14
Vehicular Cloud for the management of IP-RSUs and vehicles in the Vehicular Cloud for the management of IP-RSUs and vehicles in the
road network. A Mobility Anchor (MA) may be located in the TCC as a road network. A Mobility Anchor (MA) may be located in the TCC as a
mobility management controller, which is a controller for the mobility management controller, which is a controller for the
mobility management of vehicles. Vehicle2, Vehicle3, and Vehicle4 mobility management of vehicles. Vehicle2, Vehicle3, and Vehicle4
are wirelessly connected to IP-RSU1, IP-RSU2, and IP-RSU3, are wirelessly connected to IP-RSU1, IP-RSU2, and IP-RSU3,
respectively. The three wireless networks of IP-RSU1, IP-RSU2, and respectively. The three wireless networks of IP-RSU1, IP-RSU2, and
IP-RSU3 can belong to three different subnets (i.e., Subnet1, IP-RSU3 can belong to three different subnets (i.e., Subnet1,
Subnet2, and Subnet3), respectively. Those three subnets use three Subnet2, and Subnet3), respectively. Those three subnets use three
different prefixes (i.e., Prefix1, Prefix2, and Prefix3). different prefixes (i.e., Prefix1, Prefix2, and Prefix3).
A single subnet prefix can span multiple vehicles in VANET. For Multiple vehicles under the coverage of an RSU share a prefix such
example, in Figure 1, for Prefix 1, three vehicles (i.e., Vehicle1, that mobile nodes share a prefix of a WiFi access point in a wireless
Vehicle2, and Vehicle5) can construct a connected VANET. Also, for LAN. This is a natural characteristic in infrastructure-based
Prefix 2, two vehicles (i.e., Vehicle3 and Vehicle6) can construct wireless networks. For example, in Figure 1, two vehicles (i.e.,
another connected VANET, and for Prefix 3, two vehicles (i.e., Vehicle2, and Vehicle5) can use Prefix 1 to configure their IPv6
Vehicle4 and Vehicle7) can construct another connected VANET. global addresses for V2I communication.
A single subnet prefix announced by an RSU can span multiple vehicles
in VANET. For example, in Figure 1, for Prefix 1, three vehicles
(i.e., Vehicle1, Vehicle2, and Vehicle5) can construct a connected
VANET. Also, for Prefix 2, two vehicles (i.e., Vehicle3 and
Vehicle6) can construct another connected VANET, and for Prefix 3,
two vehicles (i.e., Vehicle4 and Vehicle7) can construct another
connected VANET.
In wireless subnets in vehicular networks (e.g., Subnet1 and Subnet2 In wireless subnets in vehicular networks (e.g., Subnet1 and Subnet2
in Figure 1), vehicles can construct a connected VANET (with an in Figure 1), vehicles can construct a connected VANET (with an
arbitrary graph topology) and can communicate with each other via V2V arbitrary graph topology) and can communicate with each other via V2V
communication. Vehicle1 can communicate with Vehicle2 via V2V communication. Vehicle1 can communicate with Vehicle2 via V2V
communication, and Vehicle2 can communicate with Vehicle3 via V2V communication, and Vehicle2 can communicate with Vehicle3 via V2V
communication because they are within the wireless communication communication because they are within the wireless communication
range for each other. On the other hand, Vehicle3 can communicate range for each other. On the other hand, Vehicle3 can communicate
with Vehicle4 via the vehicular infrastructure (i.e., IP-RSU2 and IP- with Vehicle4 via the vehicular infrastructure (i.e., IP-RSU2 and IP-
RSU3) by employing V2I (i.e., V2I2V) communication because they are RSU3) by employing V2I (i.e., V2I2V) communication because they are
skipping to change at page 12, line 24 skipping to change at page 13, line 9
based mobility management scheme (e.g., MIPv6 [RFC6275]) or a based mobility management scheme (e.g., MIPv6 [RFC6275]) or a
network-based mobility management scheme (e.g., PMIPv6 [RFC5213]). network-based mobility management scheme (e.g., PMIPv6 [RFC5213]).
In the host-based mobility scheme, an IP-RSU plays a role of a home In the host-based mobility scheme, an IP-RSU plays a role of a home
agent in a visited network. On the other hand, in the network-based agent in a visited network. On the other hand, in the network-based
mobility scheme, an MA plays a role of a mobility management mobility scheme, an MA plays a role of a mobility management
controller such as a Local Mobility Anchor (LMA) in PMIPv6, and an controller such as a Local Mobility Anchor (LMA) in PMIPv6, and an
IP-RSU plays a role of an access router such as a Mobile Access IP-RSU plays a role of an access router such as a Mobile Access
Gateway (MAG) in PMIPv6 [RFC5213]. Gateway (MAG) in PMIPv6 [RFC5213].
In vehicular networks, the control plane can be separated from the In vehicular networks, the control plane can be separated from the
data plane for efficient mobility management and data forwarding. data plane for efficient mobility management and data forwarding by
The separation of the control plane and data plane can be performed using the concept of Software-Defined Networking (SDN) [RFC7149]. In
by the Software-Defined Networking (SDN) [RFC7149]. An MA can SDN, the control plane and data plane are separated for the efficient
management of forwarding elements (e.g., switches and routers) where
an SDN controller configures the forwarding elements in a centralized
way and they perform packet forwarding according to their forwarding
tables that are configured by the SDN controller. An MA can
configure and monitor its IP-RSUs and vehicles for mobility configure and monitor its IP-RSUs and vehicles for mobility
management, location management, and security services in an management, location management, and security services as an SDN
efficient way. controller.
The mobility information of a GPS receiver mounted in its vehicle The mobility information of a GPS receiver mounted in its vehicle
(e.g., position, speed, and direction) can be used to accommodate (e.g., position, speed, and direction) can be used to accommodate
mobility-aware proactive handover schemes, which can perform the mobility-aware proactive handover schemes, which can perform the
handover of a vehicle according to its mobility and the wireless handover of a vehicle according to its mobility and the wireless
signal strength of a vehicle and an IP-RSU in a proactive way. signal strength of a vehicle and an IP-RSU in a proactive way.
Vehicles can use the TCC as their Home Network having a home agent Vehicles can use the TCC as their Home Network having a home agent
for mobility management as in MIPv6 [RFC6275] and PMIPv6 [RFC5213], for mobility management as in MIPv6 [RFC6275] and PMIPv6 [RFC5213],
so the TCC maintains the mobility information of vehicles for so the TCC maintains the mobility information of vehicles for
skipping to change at page 13, line 39 skipping to change at page 14, line 39
Vehicle1 (Moving Network1) EN1 (Fixed Network1) Vehicle1 (Moving Network1) EN1 (Fixed Network1)
<----> Wired Link <....> Wireless Link (*) Antenna <----> Wired Link <....> Wireless Link (*) Antenna
Figure 2: Internetworking between Vehicle and Edge Network Figure 2: Internetworking between Vehicle and Edge Network
4.2. V2I-based Internetworking 4.2. V2I-based Internetworking
This section discusses the internetworking between a vehicle's This section discusses the internetworking between a vehicle's
internal network (i.e., moving network) and an EN's internal network internal network (i.e., moving network) and an EN's internal network
(i.e., fixed network) via V2I communication. Note that an EN can (i.e., fixed network) via V2I communication. The internal network of
accommodate multiple routers (or switches) and servers (e.g., ECDs, a vehicle is nowadays constructed with Ethernet by many automotive
navigation server, and DNS server) in its internal network. vendors [In-Car-Network]. Note that an EN can accommodate multiple
routers (or switches) and servers (e.g., ECDs, navigation server, and
DNS server) in its internal network.
A vehicle's internal network often uses Ethernet to interconnect A vehicle's internal network often uses Ethernet to interconnect
Electronic Control Units (ECUs) in the vehicle. The internal network Electronic Control Units (ECUs) in the vehicle. The internal network
can support WiFi and Bluetooth to accommodate a driver's and can support WiFi and Bluetooth to accommodate a driver's and
passenger's mobile devices (e.g., smartphone or tablet). The network passenger's mobile devices (e.g., smartphone or tablet). The network
topology and subnetting depend on each vendor's network configuration topology and subnetting depend on each vendor's network configuration
for a vehicle and an EN. It is reasonable to consider the for a vehicle and an EN. It is reasonable to consider the
interaction between the internal network and an external network interaction between the internal network and an external network
within another vehicle or an EN. within another vehicle or an EN.
skipping to change at page 14, line 28 skipping to change at page 15, line 28
(Host3), two routers (IP-RSU1 and Router2), and the collection of (Host3), two routers (IP-RSU1 and Router2), and the collection of
servers (Server1 to ServerN) for various services in the road servers (Server1 to ServerN) for various services in the road
networks, such as the emergency notification and navigation. networks, such as the emergency notification and navigation.
Vehicle1's IP-OBU1 (as a mobile router) and EN1's IP-RSU1 (as a fixed 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 router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for
V2I networking. Thus, a host (Host1) in Vehicle1 can communicate V2I networking. Thus, a host (Host1) in Vehicle1 can communicate
with a server (Server1) in EN1 for a vehicular service through with a server (Server1) in EN1 for a vehicular service through
Vehicle1's moving network, a wireless link between IP-OBU1 and IP- Vehicle1's moving network, a wireless link between IP-OBU1 and IP-
RSU1, and EN1's fixed network. RSU1, and EN1's fixed network.
For an IPv6 communication between an IP-OBU and an IP-RSU or between For the IPv6 communication between an IP-OBU and an IP-RSU or between
two neighboring IP-OBUs, network parameters need to be shared among two neighboring IP-OBUs, they need to know the network parameters,
them, such as MAC layer and IPv6 layer information. The MAC layer which include MAC layer and IPv6 layer information. The MAC layer
information includes wireless link layer parameters, transmission information includes wireless link layer parameters, transmission
power level, the MAC address of an external network interface for the power level, the MAC address of an external network interface for the
internetworking with another IP-OBU or IP-RSU. The IPv6 layer internetworking with another IP-OBU or IP-RSU. The IPv6 layer
information includes the IPv6 address and network prefix of an information includes the IPv6 address and network prefix of an
external network interface for the internetworking with another IP- external network interface for the internetworking with another IP-
OBU or IP-RSU. OBU or IP-RSU.
Through the exchange of network parameters and network prefixes among Through the mutual knowledge of the network parameters of internal
internal networks, packets can be transmitted between the vehicle's networks, packets can be transmitted between the vehicle's moving
moving network and the EN's fixed network. Thus, V2I requires an network and the EN's fixed network. Thus, V2I requires an efficient
efficient exchange protocol for network parameters and an efficient protocol for the mutual knowledge of network parameters.
routing protocol for network prefixes.
(*)<..........>(*) (*)<..........>(*)
2001:DB8:1:1::/64 | | 2001:DB8:1:1::/64 | |
+------------------------------+ +------------------------------+ +------------------------------+ +------------------------------+
| v | | v | | v | | v |
| +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ |
| | Host1 | |IP-OBU1| | | |IP-OBU2| | Host3 | | | | Host1 | |IP-OBU1| | | |IP-OBU2| | Host3 | |
| +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ |
| ^ ^ | | ^ ^ | | ^ ^ | | ^ ^ |
| | | | | | | | | | | | | | | |
skipping to change at page 17, line 41 skipping to change at page 18, line 41
vehicular networks need to support a vehicular-network-wide DAD by vehicular networks need to support a vehicular-network-wide DAD by
defining a scope that is compatible with the legacy DAD. In this defining a scope that is compatible with the legacy DAD. In this
case, two vehicles can communicate with each other when there exists case, two vehicles can communicate with each other when there exists
a communication path over VANET or a combination of VANETs and IP- a communication path over VANET or a combination of VANETs and IP-
RSUs, as shown in Figure 1. By using the vehicular-network-wide DAD, RSUs, as shown in Figure 1. By using the vehicular-network-wide DAD,
vehicles can assure that their IPv6 addresses are unique in the vehicles can assure that their IPv6 addresses are unique in the
vehicular network whenever they are connected to the vehicular vehicular network whenever they are connected to the vehicular
infrastructure or become disconnected from it in the form of VANET. infrastructure or become disconnected from it in the form of VANET.
ND time-related parameters such as router lifetime and Neighbor ND time-related parameters such as router lifetime and Neighbor
Advertisement (NA) interval need to be adjusted for high-speed Advertisement (NA) interval need to be adjusted for vehicle speed and
vehicles and vehicle density. As vehicles move faster, the NA vehicle density. For example, the NA interval needs to be
interval should decrease (e.g., from 1 sec to 0.5 sec) for the NA dynamically adjusted according to a vehicle's speed so that the
messages to reach the neighboring vehicles promptly. Also, as vehicle can maintain its neighboring vehicles in a stable way,
vehicle density is higher, the NA interval should increase (e.g., considering the collision probability with the NA messages sent by
from 0.5 sec to 1 sec) for the NA messages to reduce collision other vehicles.
probability with other NA messages.
For IPv6-based safety applications (e.g., context-aware navigation, For IPv6-based safety applications (e.g., context-aware navigation,
adaptive cruise control, and platooning) in vehicular networks, the adaptive cruise control, and platooning) in vehicular networks, the
delay-bounded data delivery is critical. Implementations for such delay-bounded data delivery is critical. Implementations for such
applications are not available yet. IPv6 ND needs to efficiently applications are not available yet. IPv6 ND needs to efficiently
work to support IPv6-based safety applications. work to support IPv6-based safety applications.
5.1.1. Link Model 5.1.1. Link Model
A prefix model for a vehicular network needs to facilitate the A prefix model for a vehicular network needs to facilitate the
skipping to change at page 25, line 5 skipping to change at page 25, line 45
"Part 11: Wireless LAN Medium Access Control (MAC) and "Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", IEEE Std Physical Layer (PHY) Specifications", IEEE Std
802.11-2016, December 2016. 802.11-2016, December 2016.
[IEEE-802.11p] [IEEE-802.11p]
"Part 11: Wireless LAN Medium Access Control (MAC) and "Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications - Amendment 6: Physical Layer (PHY) Specifications - Amendment 6:
Wireless Access in Vehicular Environments", IEEE Std Wireless Access in Vehicular Environments", IEEE Std
802.11p-2010, June 2010. 802.11p-2010, June 2010.
[In-Car-Network]
Lim, H., Volker, L., and D. Herrscher, "Challenges in a
Future IP/Ethernet-based In-Car Network for Real-Time
Applications", ACM/EDAC/IEEE Design Automation Conference
(DAC), June 2011.
[ISO-ITS-IPv6] [ISO-ITS-IPv6]
ISO/TC 204, "Intelligent Transport Systems - ISO/TC 204, "Intelligent Transport Systems -
Communications Access for Land Mobiles (CALM) - IPv6 Communications Access for Land Mobiles (CALM) - IPv6
Networking", ISO 21210:2012, June 2012. Networking", ISO 21210:2012, June 2012.
[NHTSA-ACAS-Report] [NHTSA-ACAS-Report]
National Highway Traffic Safety Administration (NHTSA), National Highway Traffic Safety Administration (NHTSA),
"Final Report of Automotive Collision Avoidance Systems "Final Report of Automotive Collision Avoidance Systems
(ACAS) Program", DOT HS 809 080, August 2000. (ACAS) Program", DOT HS 809 080, August 2000.
skipping to change at page 26, line 21 skipping to change at page 27, line 21
November 2012. November 2012.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider Networking: A Perspective from within a Service Provider
Environment", RFC 7149, March 2014. Environment", RFC 7149, March 2014.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol Version 2", "The Optimized Link State Routing Protocol Version 2",
RFC 7181, April 2014. RFC 7181, April 2014.
[RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management",
RFC 7333, August 2014.
[RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ.
Bernardos, "Distributed Mobility Management: Current
Practices and Gap Analysis", RFC 7429, January 2015.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 8200, July 2017. (IPv6) Specification", RFC 8200, July 2017.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018. Version 1.3", RFC 8446, August 2018.
[RFC8691] Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic [RFC8691] Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic
Support for IPv6 Networks Operating Outside the Context of Support for IPv6 Networks Operating Outside the Context of
a Basic Service Set over IEEE Std 802.11", RFC 8691, a Basic Service Set over IEEE Std 802.11", RFC 8691,
December 2019. December 2019.
skipping to change at page 27, line 12 skipping to change at page 28, line 17
Networks", Springer Lecture Notes in Computer Science Networks", Springer Lecture Notes in Computer Science
(LNCS), Vol. 9502, December 2015. (LNCS), Vol. 9502, December 2015.
[Scrambler-Attack] [Scrambler-Attack]
Bloessl, B., Sommer, C., Dressier, F., and D. Eckhoff, Bloessl, B., Sommer, C., Dressier, F., and D. Eckhoff,
"The Scrambler Attack: A Robust Physical Layer Attack on "The Scrambler Attack: A Robust Physical Layer Attack on
Location Privacy in Vehicular Networks", IEEE 2015 Location Privacy in Vehicular Networks", IEEE 2015
International Conference on Computing, Networking and International Conference on Computing, Networking and
Communications (ICNC), February 2015. Communications (ICNC), February 2015.
[Timing-Attack]
Matte, C., Cunche, M., Rousseau, F., and M. Vanhoef,
"Defeating MAC Address Randomization Through Timing
Attacks", ACM the 9th ACM Conference on Security & Privacy
in Wireless and Mobile Networks (WiSec '16), July 2016.
[Truck-Platooning] [Truck-Platooning]
California Partners for Advanced Transportation Technology California Partners for Advanced Transportation Technology
(PATH), "Automated Truck Platooning", [Online] Available: (PATH), "Automated Truck Platooning", [Online] Available:
http://www.path.berkeley.edu/research/automated-and- http://www.path.berkeley.edu/research/automated-and-
connected-vehicles/truck-platooning, 2017. connected-vehicles/truck-platooning, 2017.
[TS-23.285-3GPP] [TS-23.285-3GPP]
3GPP, "Architecture Enhancements for V2X Services", 3GPP 3GPP, "Architecture Enhancements for V2X Services", 3GPP
TS 23.285, June 2018. TS 23.285, June 2018.
skipping to change at page 29, line 5 skipping to change at page 29, line 5
[WAVE-1609.3] [WAVE-1609.3]
IEEE 1609 Working Group, "IEEE Standard for Wireless IEEE 1609 Working Group, "IEEE Standard for Wireless
Access in Vehicular Environments (WAVE) - Networking Access in Vehicular Environments (WAVE) - Networking
Services", IEEE Std 1609.3-2016, April 2016. Services", IEEE Std 1609.3-2016, April 2016.
[WAVE-1609.4] [WAVE-1609.4]
IEEE 1609 Working Group, "IEEE Standard for Wireless IEEE 1609 Working Group, "IEEE Standard for Wireless
Access in Vehicular Environments (WAVE) - Multi-Channel Access in Vehicular Environments (WAVE) - Multi-Channel
Operation", IEEE Std 1609.4-2016, March 2016. Operation", IEEE Std 1609.4-2016, March 2016.
Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-12 Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-13
The following changes are made from draft-ietf-ipwave-vehicular- The following changes are made from draft-ietf-ipwave-vehicular-
networking-12: networking-13:
o This version is revised based on the comments from Carlos o This version is revised based on the comments from Carlos
Bernardos. Bernardos.
o This version focuses on problems rather than solutions for IPWAVE. o The definition of Mobility Anchor (MA) is clarified with a
Also, this version addresses the requirements of IPv6 neighbor reference to PMIPv6.
discovery, mobility management, and security and privacy.
o In Section 2, IP-OBU and IP-RSU are used instead of OBU and RSU, o In Vehicular Neighbor Discovery, Vehicular Mobility Management,
respectively. and Vehicular Security and Privacy, the prefix of "Vehicular" is
explained to represent extensions of the existing protocols rather
than new "vehicular-specific" functions.
o In Section 4.1, an exemplary vehicular network architecture is o In Section 4.1, an exemplary vehicular network architecture is
illustrated for the problem statement as Figure 1. explained as an extension of the existing network architecture of
PMIPv6 for multi-hop V2V, V2I, and V2X (or V2I2X).
o For the IPv6 communication between an IP-OBU and an IP-RSU or
between two neighboring IP-OBUs, the requirements of knowing the
network parameters are addressed rather than the network parameter
sharing as a solution.
o In Figure 1, the prefix sharing of multiple vehicles under an RSU
is explained such that it is the same as the prefix sharing in a
WiFi LAN.
o The separation of the control plane and data plane is explained by
referring to the concept of SDN and the relationship between the
SDN controller and forwarding elements.
o In Figure 2, the topology of a vehicle's internal network is
justified with the reference to a real car network
[In-Car-Network].
o The discussion on ND timers is modified, focusing on a problem
rather than a solution.
Appendix B. Acknowledgments Appendix B. Acknowledgments
This work was supported by Basic Science Research Program through the This work was supported by Institute of Information & Communications
National Research Foundation of Korea (NRF) funded by the Ministry of Technology Planning & Evaluation (IITP) grant funded by the Korea
Education (2017R1D1A1B03035885). 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 This work was supported in part by the MSIT (Ministry of Science and
ICT), Korea, under the ITRC (Information Technology Research Center) ICT), Korea, under the ITRC (Information Technology Research Center)
support program (IITP-2019-2017-0-01633) supervised by the IITP support program (IITP-2019-2017-0-01633) supervised by the IITP
(Institute for Information & communications Technology Promotion). (Institute for Information & communications Technology Promotion).
This work was supported in part by the French research project This work was supported in part by the French research project
DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded
by the European Commission I (636537-H2020). by the European Commission I (636537-H2020).
 End of changes. 31 change blocks. 
81 lines changed or deleted 155 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/