draft-ietf-ipwave-vehicular-networking-23.txt   draft-ietf-ipwave-vehicular-networking-24.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 9 October 2021
Expires: 6 March 2022 Expires: 12 April 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-23 draft-ietf-ipwave-vehicular-networking-24
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 1, line 41 skipping to change at page 1, line 41
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 6 March 2022. This Internet-Draft will expire on 12 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 42 skipping to change at page 2, line 42
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 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 . . . . . . . 47
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 47 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 48
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 48 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50
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-
based wireless communications can support vehicle-to-vehicle (V2V), based wireless communications can support vehicle-to-vehicle (V2V),
skipping to change at page 3, line 46 skipping to change at page 3, line 46
[TR-22.886-3GPP][TS-23.287-3GPP]. With C-V2X, vehicles can directly [TR-22.886-3GPP][TS-23.287-3GPP]. With C-V2X, vehicles can directly
communicate with each other without relay nodes (e.g., eNodeB in LTE communicate with each other without relay nodes (e.g., eNodeB in LTE
and gNodeB in 5G). and gNodeB in 5G).
Along with these WAVE standards and C-V2X standards, regardless of a Along with these WAVE standards and C-V2X standards, regardless of a
wireless access technology under the IP stack of a vehicle, vehicular wireless access technology under the IP stack of a vehicle, vehicular
networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6 networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6
protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6) protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6)
[RFC5213], Distributed Mobility Management (DMM) [RFC7333], Network [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Network
Mobility (NEMO) [RFC3963], Locator/ID Separation Protocol (LISP) Mobility (NEMO) [RFC3963], Locator/ID Separation Protocol (LISP)
[RFC6830BIS], and Asymmetric Extended Route Optimization (AERO) [RFC6830BIS], and Automatic Extended Route Optimization (AERO)
[RFC6706BIS]). In addition, ISO has approved a standard specifying [AERO]). In addition, ISO has approved a standard specifying the
the IPv6 network protocols and services to be used for Communications IPv6 network protocols and services to be used for Communications
Access for Land Mobiles (CALM) [ISO-ITS-IPv6][ISO-ITS-IPv6-AMD1]. Access for Land Mobiles (CALM) [ISO-ITS-IPv6][ISO-ITS-IPv6-AMD1].
This document describes use cases and a problem statement about This document describes use cases and a problem statement about
IPv6-based vehicular networking for ITS, which is named IPv6 Wireless IPv6-based vehicular networking for ITS, which is named IPv6 Wireless
Access in Vehicular Environments (IPWAVE). First, it introduces the Access in Vehicular Environments (IPWAVE). First, it introduces the
use cases for using V2V, V2I, and V2X networking in ITS. Next, for use cases for using V2V, V2I, and V2X networking in ITS. Next, for
IPv6-based vehicular networks, it makes a gap analysis of current IPv6-based vehicular networks, it makes a gap analysis of current
IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management,
and Security & Privacy), and then enumerates requirements for the and Security & Privacy), and then enumerates requirements for the
extensions of those IPv6 protocols, which are tailored to IPv6-based extensions of those IPv6 protocols, which are tailored to IPv6-based
skipping to change at page 15, line 37 skipping to change at page 15, line 37
communication continuity in vehicular networks so that a vehicle's communication continuity in vehicular networks so that a vehicle's
TCP session can be continued, or UDP packets can be delivered to a TCP session can be continued, or UDP packets can be delivered to a
vehicle as a destination without loss while it moves from an IP-RSU's vehicle as a destination without loss while it moves from an IP-RSU's
wireless coverage to another IP-RSU's wireless coverage. In wireless coverage to another IP-RSU's wireless coverage. In
Figure 1, assuming that Vehicle2 has a TCP session (or a UDP session) Figure 1, assuming that Vehicle2 has a TCP session (or a UDP session)
with a corresponding node in the vehicular cloud, Vehicle2 can move with a corresponding node in the vehicular cloud, Vehicle2 can move
from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage. In from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage. In
this case, a handover for Vehicle2 needs to be performed by either a this case, a handover for Vehicle2 needs to be performed by either a
host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a
network-based mobility management scheme (e.g., PMIPv6 [RFC5213] and network-based mobility management scheme (e.g., PMIPv6 [RFC5213] and
AERO [RFC6706BIS]). This document describes issues in mobility AERO [AERO]). This document describes issues in mobility management
management for vehicular networks in Section 5.2. for vehicular networks in Section 5.2.
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. The internal network of (i.e., fixed network) via V2I communication. The internal network of
a vehicle is nowadays constructed with Ethernet by many automotive a vehicle is nowadays constructed with Ethernet by many automotive
vendors [In-Car-Network]. Note that an EN can accommodate multiple vendors [In-Car-Network]. Note that an EN can accommodate multiple
routers (or switches) and servers (e.g., ECDs, navigation server, and routers (or switches) and servers (e.g., ECDs, navigation server, and
DNS server) in its internal network. DNS server) in its internal network.
skipping to change at page 28, line 4 skipping to change at page 28, line 4
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 Destination-Oriented networks, which constructs and maintains Destination-Oriented
Directed Acyclic Graphs (DODAGs) optimized by an Objective Function Directed Acyclic Graphs (DODAGs) optimized by an Objective Function
(OF). A defined OF provides route selection and optimization within (OF). A defined OF provides route selection and optimization within
an RPL topology. A node in a DODAG discovers and maintains the an RPL topology. The RPL nodes use an anisotropic Distance Vector
upward routes toward the root node of the DODAG. RPL uses a Distance (DV) approach to form a DODAG by discovering and aggressively
Vector (DV) approach, with lazy maintenance and stretched anisotropic maintaining the upward default route toward the root of the DODAG.
routing. It is well-designed to reduce the topological knowledge and Downward routes follow the same DODAG, with lazy maintenance and
routing state that needs to be exchanged. As a result, the routing stretched Peer-to-Peer (P2P) routing in the so-called storing mode.
protocol overhead is minimized, which allows either highly It is well-designed to reduce the topological knowledge and routing
constrained stable networks or less constrained, highly dynamic state that needs to be exchanged. As a result, the routing protocol
networks. Refer to Appendix B for the detailed description of RPL overhead is minimized, which allows either highly constrained stable
for multihop V2X networking. 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. [RFC8505], as mobility for nodes moving through different parents. [RFC8505], as
opposed to [RFC4861], is stateful and proactively installs the ND opposed to [RFC4861], is stateful and proactively installs the ND
cache entries, which saves broadcasts and provides a deterministic cache entries, which saves broadcasts and provides a deterministic
presence information for IPv6 addresses. Mainly it updates the presence information for IPv6 addresses. Mainly it updates the
Address Registration Option (ARO) of ND defined in [RFC6775] to Address Registration Option (ARO) of ND defined in [RFC6775] to
include a status field that can indicate the movement of a node and 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 optionally a Transaction ID (TID) field, i.e., a sequence number that
skipping to change at page 40, line 5 skipping to change at page 40, line 5
ippl-00>. ippl-00>.
[RFC6830BIS] [RFC6830BIS]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, "The Locator/ID Separation Protocol (LISP)", Cabellos, "The Locator/ID Separation Protocol (LISP)",
Work in Progress, Internet-Draft, draft-ietf-lisp- Work in Progress, Internet-Draft, draft-ietf-lisp-
rfc6830bis-36, November 2020, rfc6830bis-36, November 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp- <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
rfc6830bis-36>. rfc6830bis-36>.
[RFC6706BIS] [AERO] Templin, F., "Automatic Extended Route Optimization
Templin, F., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin- (AERO)", Work in Progress, Internet-Draft, draft-templin-
intarea-6706bis-99, March 2021, 6man-aero-34, September 2021,
<https://datatracker.ietf.org/doc/html/draft-templin- <https://datatracker.ietf.org/doc/html/draft-templin-6man-
intarea-6706bis-99>. aero-34>.
[OMNI] Templin, F. and A. Whyman, "Transmission of IP Packets [OMNI] Templin, F. and A. Whyman, "Transmission of IP Packets
over Overlay Multilink Network (OMNI) Interfaces", Work in over Overlay Multilink Network (OMNI) Interfaces", Work in
Progress, Internet-Draft, draft-templin-6man-omni-41, Progress, Internet-Draft, draft-templin-6man-omni-47,
August 2021, <https://datatracker.ietf.org/doc/html/draft- September 2021, <https://datatracker.ietf.org/doc/html/
templin-6man-omni-41>. draft-templin-6man-omni-47>.
[UAM-ITS] Templin, F., "Urban Air Mobility Implications for [UAM-ITS] Templin, F., "Urban Air Mobility Implications for
Intelligent Transportation Systems", Work in Progress, Intelligent Transportation Systems", Work in Progress,
Internet-Draft, draft-templin-ipwave-uam-its-04, January Internet-Draft, draft-templin-ipwave-uam-its-04, January
2021, <https://datatracker.ietf.org/doc/html/draft- 2021, <https://datatracker.ietf.org/doc/html/draft-
templin-ipwave-uam-its-04>. templin-ipwave-uam-its-04>.
[DMM-FPC] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., [DMM-FPC] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
Moses, D., and C. Perkins, "Protocol for Forwarding Policy Moses, D., and C. Perkins, "Protocol for Forwarding Policy
Configuration (FPC) in DMM", Work in Progress, Internet- Configuration (FPC) in DMM", Work in Progress, Internet-
skipping to change at page 45, line 8 skipping to change at page 45, line 8
protocol changes in order to support both wireless single-hop/ protocol changes in order to support both wireless single-hop/
multihop V2V communications and multiple radio technologies in multihop V2V communications and multiple radio technologies in
vehicular networks. In such a way, vehicles can communicate with vehicular networks. In such a way, vehicles can communicate with
each other by V2V communications to share either an emergency each other by V2V communications to share either an emergency
situation or road hazard information in a highway having multiple situation or road hazard information in a highway having multiple
kinds of radio technologies. kinds of radio technologies.
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 AERO
Multilink Network Interface (OMNI) [OMNI]. (Automatic Extended Route Optimization) [AERO] over OMNI (Overlay
Multilink Network Interface) [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,
skipping to change at page 45, line 37 skipping to change at page 45, line 38
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 (DV) To reduce the routing exchanges, RPL leverages a DV approach, which
approach, which does not need a global knowledge of the topology, and does not need a global knowledge of the topology, and only optimizes
only optimizes the routes to and from the root, allowing Peer-to-Peer the routes to and from the root, allowing P2P paths to be stretched.
(P2P) paths to be stretched. Although RPL installs its routes Although RPL installs its routes proactively, it only maintains them
proactively, it only maintains them lazily, that is, in reaction to lazily, that is, in reaction to actual traffic, or as a slow
actual traffic, or as a slow background activity. Additionally, RPL background activity. Additionally, RPL leverages the concept of an
leverages the concept of an objective function (called OF), which objective function (called OF), which allows to adapt the activity of
allows to adapt the activity of the routing protocol to use cases, the routing protocol to use cases, e.g., type, speed, and quality of
e.g., type, speed, and quality of the radios. RPL does not need the radios. RPL does not need converge, and provides connectivity to
converge, and provides connectivity to most nodes most of the time. most nodes most of the time. The default route toward the root is
The default route toward the root is maintained aggressively and may maintained aggressively and may change while a packet progresses
change while a packet progresses without causing loops, so the packet without causing loops, so the packet will still reach the root.
will still reach the root. There are two modes for routing in RPL There are two modes for routing in RPL such as non-storing mode and
such as non-storing mode and storing mode. In non-storing mode, a storing mode. In non-storing mode, a node inside the mesh/swarm that
node inside the mesh/swarm that changes its point(s) of attachment to changes its point(s) of attachment to the graph informs the root with
the graph informs the root with a single unicast packet flowing along a single unicast packet flowing along the default route, and the
the default route, and the connectivity is restored immediately; this connectivity is restored immediately; this mode is preferable for use
mode is preferable for use cases where Internet connectivity is cases where Internet connectivity is dominant. On the other hand, in
dominant. On the other hand, in storing mode, the routing stretch is storing mode, the routing stretch is reduced, for a better P2P
reduced, for a better P2P connectivity, while the Internet connectivity, while the Internet connectivity is restored more
connectivity is restored more slowly, during the time for the DV slowly, during the time for the DV operation to operate hop-by-hop.
operation to operate hop-by-hop. While an RPL topology can quickly While an RPL topology can quickly scale up and down and fits the
scale up and down and fits the needs of mobility of vehicles, the needs of mobility of vehicles, the total performance of the system
total performance of the system will also depend on how quickly a will also depend on how quickly a node can form an address, join the
node can form an address, join the mesh (including Authentication, mesh (including Authentication, Authorization, and Accounting (AAA)),
Authorization, and Accounting (AAA)), and manage its global mobility and manage its global mobility to become reachable from another node
to become reachable from another node outside the mesh. outside the mesh.
OMNI defines a protocol for the transmission of IPv6 packets over AERO and OMNI together securely and efficiently address the following
Overlay Multilink Network Interfaces that are virtual interfaces 6 M's of Modern Internetworking for mobile V2V, V2I and V2X Clients:
governing multiple physical network interfaces. OMNI supports
multihop V2V communication between vehicles in multiple forwarding 1. Multilink: A Client's ability to coordinate multiple diverse
hops via intermediate vehicles with OMNI links. It also supports underlying data links as a single logical unit (i.e., the OMNI
multihop V2I communication between a vehicle and an infrastructure interface) to achieve the required communications performance and
access point by multihop V2V communication. The OMNI interface reliability objectives.
supports an NBMA link model where multihop V2V and V2I communications
use each mobile node's ULAs without need for any DAD or MLD 2. Multinet: The ability to span the OMNI link over a segment
Messaging. routing topology with multiple diverse administrative domain
network segments while maintaining seamless E2E communications
between mobile Clients and correspondents such as air traffic
controllers and fleet administrators.
3. Mobility: A Client's ability to change network points of
attachment (e.g., moving between wireless base stations) which
may result in an underlying interface address change without
disruptions to ongoing communication sessions with peers over the
OMNI link.
4. Multicast: The ability to send a single network transmission that
reaches multiple Clients belonging to the same interest group
without disturbing other Clients not subscribed to the interest
group.
5. Multihop: A mobile Client's V2V relaying capability useful when
multiple forwarding hops between vehicles may be necessary to
reach back to an infrastructure access point connection to the
OMNI link.
6. MTU Assurance: The ability to deliver packets of various robust
sizes between peers without loss due to a link size restriction,
and to dynamically adjust packet sizes in order to achieve the
optimal performance for each independent traffic flow.
Appendix C. Support of Mobility Management for V2I Appendix C. Support of Mobility Management for V2I
The seamless application communication between two vehicles or The seamless application communication between two vehicles or
between a vehicle and an infrastructure node requires mobility between a vehicle and an infrastructure node requires mobility
management in vehicular networks. The mobility management schemes management in vehicular networks. The mobility management schemes
include a host-based mobility scheme, network-based mobility scheme, include a host-based mobility scheme, network-based mobility scheme,
and software-defined networking scheme. and software-defined networking scheme.
In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a
skipping to change at page 47, line 46 skipping to change at page 48, line 20
This work was supported by Institute of Information & Communications This work was supported by Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea Technology Planning & Evaluation (IITP) grant funded by the Korea
MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based
Security Intelligence Technology Development for the Customized Security Intelligence Technology Development for the Customized
Security Service Provisioning). Security Service Provisioning).
This work was supported in part by the MSIT, Korea, under the ITRC This work was supported in part by the MSIT, Korea, under the ITRC
(Information Technology Research Center) support program (IITP- (Information Technology Research Center) support program (IITP-
2021-2017-0-01633) supervised by the IITP. 2021-2017-0-01633) supervised by the IITP.
This work was supported in part by the IITP grant funded by the MSIT
(2020-0-00395, Standard Development of Blockchain based Network
Management Automation Technology).
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).
This work was supported in part by the Cisco University Research This work was supported in part by the Cisco University Research
Program Fund, Grant # 2019-199458 (3696), and by ANID Chile Basal Program Fund, Grant # 2019-199458 (3696), and by ANID Chile Basal
Project FB0008. Project FB0008.
Appendix E. Contributors Appendix E. Contributors
 End of changes. 15 change blocks. 
68 lines changed or deleted 98 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/