draft-ietf-ipwave-vehicular-networking-22.txt   draft-ietf-ipwave-vehicular-networking-23.txt 
IPWAVE Working Group J. Jeong, Ed. IPWAVE Working Group J. Jeong, Ed.
Internet-Draft Sungkyunkwan University Internet-Draft Sungkyunkwan University
Intended status: Informational 2 September 2021 Intended status: Informational 2 September 2021
Expires: 6 March 2022 Expires: 6 March 2022
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-22 draft-ietf-ipwave-vehicular-networking-23
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, for explains use cases using V2V, V2I, and V2X networking. Next, for
IPv6-based vehicular networks, it makes a gap analysis of current IPv6-based vehicular networks, it makes a gap analysis of current
skipping to change at page 2, line 31 skipping to change at page 2, line 31
3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 12 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 12
4.1. Vehicular Network Architecture . . . . . . . . . . . . . 14 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 14
4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 15 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 15
4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 18 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 18
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 22 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 23 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 23
5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 25 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 25
5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 27 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 27
5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 27 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 28 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6.1. Security Threats in Neighbor Discovery . . . . . . . . . 32 6.1. Security Threats in Neighbor Discovery . . . . . . . . . 32
6.2. Security Threats in Mobility Management . . . . . . . . . 33 6.2. Security Threats in Mobility Management . . . . . . . . . 33
6.3. Other Threats . . . . . . . . . . . . . . . . . . . . . . 33 6.3. Other Threats . . . . . . . . . . . . . . . . . . . . . . 33
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. Normative References . . . . . . . . . . . . . . . . . . 35 8.1. Normative References . . . . . . . . . . . . . . . . . . 35
8.2. Informative References . . . . . . . . . . . . . . . . . 39 8.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Support of Multiple Radio Technologies for V2V . . . 44 Appendix A. Support of Multiple Radio Technologies for V2V . . . 44
Appendix B. Support of Multihop V2X Networking . . . . . . . . . 45 Appendix B. Support of Multihop V2X Networking . . . . . . . . . 45
Appendix C. Support of Mobility Management for V2I . . . . . . . 46 Appendix C. Support of Mobility Management for V2I . . . . . . . 46
skipping to change at page 27, line 50 skipping to change at page 27, line 50
control traffic overhead [ID-Multicast-Problems]. control traffic overhead [ID-Multicast-Problems].
A routing protocol for a VANET may cause redundant wireless frames in A routing protocol for a VANET may cause redundant wireless frames in
the air to check the neighborhood of each vehicle and compute the the air to check the neighborhood of each vehicle and compute the
routing information in a VANET with a dynamic network topology routing information in a VANET with a dynamic network topology
because the IPv6 ND is used to check the neighborhood of each because the IPv6 ND is used to check the neighborhood of each
vehicle. Thus, the vehicular routing needs to take advantage of the vehicle. Thus, the vehicular routing needs to take advantage of the
IPv6 ND to minimize its control overhead. IPv6 ND to minimize its control overhead.
RPL [RFC6550] defines a routing protocol for low-power and lossy RPL [RFC6550] defines a routing protocol for low-power and lossy
networks, which constructs and maintains DODAGs optimized by an networks, which constructs and maintains Destination-Oriented
Objective Function (OF). A defined OF provides route selection and Directed Acyclic Graphs (DODAGs) optimized by an Objective Function
optimization within an RPL topology. A node in a DODAG uses DODAG (OF). A defined OF provides route selection and optimization within
Information Objects (DIOs) messages to discover and maintain the an RPL topology. A node in a DODAG discovers and maintains the
upward routes toward the root node. Refer to Appendix B for the upward routes toward the root node of the DODAG. RPL uses a Distance
detailed description of RPL for multihop V2X networking. Vector (DV) approach, with lazy maintenance and stretched anisotropic
routing. It is well-designed to reduce the topological knowledge and
routing state that needs to be exchanged. As a result, the routing
protocol overhead is minimized, which allows either highly
constrained stable networks or less constrained, highly dynamic
networks. Refer to Appendix B for the detailed description of RPL
for multihop V2X networking.
An address registration extension for 6LoWPAN (IPv6 over Low-Power An address registration extension for 6LoWPAN (IPv6 over Low-Power
Wireless Personal Area Network) in [RFC8505] can support light-weight Wireless Personal Area Network) in [RFC8505] can support light-weight
mobility for nodes moving through different parents. Mainly it mobility for nodes moving through different parents. [RFC8505], as
updates the Address Registration Option (ARO) of ND defined in opposed to [RFC4861], is stateful and proactively installs the ND
[RFC6775] to include a status field that can indicate the movement of cache entries, which saves broadcasts and provides a deterministic
a node and optionally a Transaction ID (TID) field, i.e., a sequence presence information for IPv6 addresses. Mainly it updates the
number that can be used to determine the most recent location of a Address Registration Option (ARO) of ND defined in [RFC6775] to
node. 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
RPL can use the information provided by the extended ARO defined in can be used to determine the most recent location of a node. Thus,
[RFC8505] to deal with a certain level of node mobility. When a leaf RPL can use the information provided by the Extended ARO (EARO)
node moves to the coverage of another parent node, it should de- defined in [RFC8505] to deal with a certain level of node mobility.
register its addresses to the previous parent node and register When a leaf node moves to the coverage of another parent node, it
itself with a new parent node along with an incremented TID. should de-register its addresses to the previous parent node and
register itself with a new parent node along with an incremented TID.
RPL can be used in IPv6-based vehicular networks, but it is primarily RPL can be used in IPv6-based vehicular networks, but it is primarily
designed for lossy networks, which puts energy efficiency first. For designed for lossy networks, which puts energy efficiency first. For
using it in IPv6-based vehicular networks, there have not been actual using it in IPv6-based vehicular networks, there have not been actual
experiences and practical implementations for vehicular networks, experiences and practical implementations for vehicular networks,
though it was tested in IoT low-power and lossy networks (LLN) though it was tested in IoT low-power and lossy networks (LLN)
scenarios. scenarios.
Moreover, due to bandwidth and energy constraints, RPL does not Moreover, due to bandwidth and energy constraints, RPL does not
suggest to use a proactive mechanism (e.g., keepalive) to maintain suggest to use a proactive mechanism (e.g., keepalive) to maintain
skipping to change at page 45, line 14 skipping to change at page 45, line 14
Appendix B. Support of Multihop V2X Networking Appendix B. Support of Multihop V2X Networking
The multihop V2X networking can be supported by RPL (IPv6 Routing The multihop V2X networking can be supported by RPL (IPv6 Routing
Protocol for Low-Power and Lossy Networks) [RFC6550] and Overlay Protocol for Low-Power and Lossy Networks) [RFC6550] and Overlay
Multilink Network Interface (OMNI) [OMNI]. Multilink Network Interface (OMNI) [OMNI].
RPL defines an IPv6 routing protocol for low-power and lossy networks RPL defines an IPv6 routing protocol for low-power and lossy networks
(LLN), mostly designed for home automation routing, building (LLN), mostly designed for home automation routing, building
automation routing, industrial routing, and urban LLN routing. It automation routing, industrial routing, and urban LLN routing. It
uses a destination oriented directed acyclic graph (DODAG) to uses a Destination-Oriented Directed Acyclic Graph (DODAG) to
construct routing paths for hosts (e.g., IoT devices) in a network. construct routing paths for hosts (e.g., IoT devices) in a network.
The DODAG uses an objective function (OF) for route selection and The DODAG uses an objective function (OF) for route selection and
optimization within the network. A user can use different routing optimization within the network. A user can use different routing
metrics to define an OF for a specific scenario. RPL supports metrics to define an OF for a specific scenario. RPL supports
multipoint-to-point, point-to-multipoint, and point-to-point traffic, multipoint-to-point, point-to-multipoint, and point-to-point traffic,
and the major traffic flow is the multipoint-to-point traffic. For and the major traffic flow is the multipoint-to-point traffic. For
example, in a highway scenario, a vehicle may not access an RSU 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). 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 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 a vehicle can take advantage of other vehicles as relay nodes to
skipping to change at page 45, line 37 skipping to change at page 45, line 37
RPL is primarily designed to minimize the control plane activity, RPL is primarily designed to minimize the control plane activity,
which is the relative amount of routing protocol exchanges versus which is the relative amount of routing protocol exchanges versus
data traffic; this approach is beneficial for situations where the data traffic; this approach is beneficial for situations where the
power and bandwidth are scarce (e.g., an IoT LLN where RPL is power and bandwidth are scarce (e.g., an IoT LLN where RPL is
typically used today), but also in situations of high relative typically used today), but also in situations of high relative
mobility between the nodes in the network (also known as swarming, mobility between the nodes in the network (also known as swarming,
e.g., within a variable set of vehicles with a similar global motion, e.g., within a variable set of vehicles with a similar global motion,
or a variable set of drones flying toward the same direction). or a variable set of drones flying toward the same direction).
To reduce the routing exchanges, RPL leverages a Distance Vector To reduce the routing exchanges, RPL leverages a Distance Vector (DV)
approach, which does not need a global knowledge of the topology, and 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 only optimizes the routes to and from the root, allowing Peer-to-Peer
(P2P) paths to be stretched. Although RPL installs its routes (P2P) paths to be stretched. Although RPL installs its routes
proactively, it only maintains them lazily, that is, in reaction to proactively, it only maintains them lazily, that is, in reaction to
actual traffic, or as a slow background activity. Additionally, RPL actual traffic, or as a slow background activity. Additionally, RPL
leverages the concept of an objective function (called OF), which leverages the concept of an objective function (called OF), which
allows to adapt the activity of the routing protocol to use cases, 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 e.g., type, speed, and quality of the radios. RPL does not need
converge, and provides connectivity to most nodes most of the time. converge, and provides connectivity to most nodes most of the time.
The default route toward the root is maintained aggressively and may The default route toward the root is maintained aggressively and may
 End of changes. 6 change blocks. 
23 lines changed or deleted 30 lines changed or added

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