< draft-jeong-ipwave-vehicular-neighbor-discovery-05.txt   draft-jeong-ipwave-vehicular-neighbor-discovery-06.txt >
IPWAVE Working Group J. Jeong IPWAVE Working Group J. Jeong
Internet-Draft Y. Shen Internet-Draft Y. Shen
Intended status: Standards Track Z. Xiang Intended status: Standards Track Z. Xiang
Expires: May 12, 2019 Sungkyunkwan University Expires: September 12, 2019 Sungkyunkwan University
November 8, 2018 March 11, 2019
IPv6 Neighbor Discovery for IP-Based Vehicular Networks IPv6 Neighbor Discovery for IP-Based Vehicular Networks
draft-jeong-ipwave-vehicular-neighbor-discovery-05 draft-jeong-ipwave-vehicular-neighbor-discovery-06
Abstract Abstract
This document specifies a Vehicular Neighbor Discovery (VND) as an This document specifies a Vehicular Neighbor Discovery (VND) as an
extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular
networks. An optimized Address Registration and a multihop Duplicate networks. An optimized Address Registration and a multihop Duplicate
Address Detection (DAD) mechanism are established for both operation Address Detection (DAD) mechanism are performed for having operation
efficiency and the saving of wireless bandwidth and vehicle energy. efficiency and also saving both wireless bandwidth and vehicle
Also, the three new ND options for prefix discovery, service energy. Also, three new ND options for prefix discovery, service
discovery, and mobility information report are used to announce the discovery, and mobility information report are defined to announce
network prefixes and services inside a vehicle (i.e., a vehicle's the network prefixes and services inside a vehicle (i.e., a vehicle's
internal network). Finally, a mobility management scheme is proposed internal network). Finally, a mobility management scheme is proposed
for moving vehicles in vehicular environments to support seamless for moving vehicles in vehicular environments to support seamless
communication for the continuity of transport-layer sessions (e.g., communication for the continuity of transport-layer sessions (e.g.,
TCP connections). TCP connections).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 12, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. ND Optimization . . . . . . . . . . . . . . . . . . . . . 5 4.2. ND Optimization . . . . . . . . . . . . . . . . . . . . . 6
4.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 6
5. Vehicular Network Architecture . . . . . . . . . . . . . . . 6 5. Vehicular Network Architecture . . . . . . . . . . . . . . . 7
5.1. Vehicular Network . . . . . . . . . . . . . . . . . . . . 6 5.1. Vehicular Network . . . . . . . . . . . . . . . . . . . . 7
5.2. V2I Internetworking . . . . . . . . . . . . . . . . . . . 9 5.2. V2I Internetworking . . . . . . . . . . . . . . . . . . . 9
5.3. V2V Internetworking . . . . . . . . . . . . . . . . . . . 9 5.3. V2V Internetworking . . . . . . . . . . . . . . . . . . . 10
6. ND Extension for Prefix and Service Discovery . . . . . . . . 11 6. ND Extension for Prefix and Service Discovery . . . . . . . . 11
6.1. Vehicular Prefix Information Option . . . . . . . . . . . 11 6.1. Vehicular Prefix Information Option . . . . . . . . . . . 11
6.2. Vehicular Service Information Option . . . . . . . . . . 12 6.2. Vehicular Service Information Option . . . . . . . . . . 12
6.3. Vehicular Mobility Information Option . . . . . . . . . . 13 6.3. Vehicular Mobility Information Option . . . . . . . . . . 13
6.4. Vehicular Neighbor Discovery . . . . . . . . . . . . . . 14 6.4. Vehicular Neighbor Discovery . . . . . . . . . . . . . . 14
6.5. Message Exchange Procedure for V2I Networking . . . . . . 14 6.5. Message Exchange Procedure for V2I Networking . . . . . . 15
7. Address Registration and Duplicate Address Detection . . . . 16 7. Address Registration and Duplicate Address Detection . . . . 16
7.1. Address Autoconfiguration . . . . . . . . . . . . . . . . 16 7.1. Address Autoconfiguration . . . . . . . . . . . . . . . . 17
7.2. Address Registration . . . . . . . . . . . . . . . . . . 16 7.2. Address Registration . . . . . . . . . . . . . . . . . . 17
7.3. Multihop Duplicate Address Detection . . . . . . . . . . 17 7.3. Multihop Duplicate Address Detection . . . . . . . . . . 18
7.4. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 19 7.4. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 21
8. Mobility Management . . . . . . . . . . . . . . . . . . . . . 19 8. Mobility Management . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor- Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor-
discovery-04 . . . . . . . . . . . . . . . . . . . . 24 discovery-05 . . . . . . . . . . . . . . . . . . . . 27
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 24 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Vehicular Ad Hoc Networks (VANET) have been researched for Vehicular Ad Hoc Networks (VANET) have been researched for
Intelligent Transportation System (ITS) such as driving safety, Intelligent Transportation System (ITS) such as driving safety,
efficient driving and entertainment. Considering the high-speed efficient driving and entertainment. Considering the high-speed
mobility of vehicular network based on Dedicated Short-Range mobility of vehicular network based on Dedicated Short-Range
Communications (DSRC), IEEE 802.11p [IEEE-802.11p] has been Communications (DSRC), IEEE 802.11p [IEEE-802.11p] has been
specialized and was renamed IEEE 802.11 Outside the Context of a specialized and was renamed IEEE 802.11 Outside the Context of a
Basic Service Set (OCB) [IEEE-802.11-OCB] in 2012. IEEE has Basic Service Set (OCB) [IEEE-802.11-OCB] in 2012. IEEE has
skipping to change at page 3, line 35 skipping to change at page 3, line 35
connections, and moderate power constraint (e.g., electric cars and connections, and moderate power constraint (e.g., electric cars and
unmanned aerial vehicles). Links among hosts and routers in VANET unmanned aerial vehicles). Links among hosts and routers in VANET
can be considered as undetermined connectivities with constantly can be considered as undetermined connectivities with constantly
changing neighbors described in [RFC5889]. IPv6 [RFC8200] is changing neighbors described in [RFC5889]. IPv6 [RFC8200] is
selected as the network-layer protocol for Internet applications by selected as the network-layer protocol for Internet applications by
IEEE 1609.0 and 1609.3. However, the relatively long-time Neighbor IEEE 1609.0 and 1609.3. However, the relatively long-time Neighbor
Discovery (ND) process in IPv6 [RFC4861] is not suitable in VANET Discovery (ND) process in IPv6 [RFC4861] is not suitable in VANET
scenarios. scenarios.
To support the interaction between vehicles or between vehicles and To support the interaction between vehicles or between vehicles and
Rode-Side Unit (RSU), this document specifies a Vehicular Neighbor Rode-Side Units (RSUs), this document specifies a Vehicular Neighbor
Discovery (VND) as an extension of IPv6 ND for IP-based vehicular Discovery (VND) as an extension of IPv6 ND for IP-based vehicular
networks. VND provides vehicles with an optimized Address networks. VND provides vehicles with an optimized Address
Registration, a multihop Duplicate Address Detection (DAD), and an Registration, a multihop Duplicate Address Detection (DAD), and an
efficient mobility management scheme to support efficient V2V, V2I, efficient mobility management scheme to support efficient V2V, V2I,
and V2X communications. and V2X communications.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 4, line 44 skipping to change at page 4, line 44
infrastructure information (e.g., RSUs, traffic signals, and loop infrastructure information (e.g., RSUs, traffic signals, and loop
detectors), vehicular traffic statistics (e.g., average vehicle detectors), vehicular traffic statistics (e.g., average vehicle
speed and vehicle inter-arrival time per road segment), and speed and vehicle inter-arrival time per road segment), and
vehicle information (e.g., a vehicle's identifier, position, vehicle information (e.g., a vehicle's identifier, position,
direction, speed, and trajectory as a navigation path). TCC is direction, speed, and trajectory as a navigation path). TCC is
included in a vehicular cloud for vehicular networks and has MAs included in a vehicular cloud for vehicular networks and has MAs
under its management. under its management.
4. Overview 4. Overview
This document proposes an optimized ND, which has a more adaptive This document proposes an optimized ND with a more adaptive structure
structure for vehicular networks considering fast vehicle mobility for vehicular networks considering fast vehicle mobility and wireless
and wireless control traffic overhead related to the ND. Further control traffic overhead related to the legacy ND. Further more,
more, prefix and service discovery can be implemented as part of the prefix and service discovery can be implemented as part of the ND's
ND's process along with an efficient Address Registration procedure process along with an efficient Address Registration procedure and
and DAD mechanism for moving vehicles. This document specifies a set DAD mechanism for moving vehicles. This document specifies a set of
of behaviors between vehicles and RSUs to accomplish these goals. behaviors between vehicles and RSUs to accomplish these goals.
4.1. Link Model 4.1. Link Model
There is a relationship between a link and a network prefix along There is a relationship between a link and a network prefix along
with reachability scopes, such as link-local and global scopes. The with reachability scopes, such as link-local and global scopes. The
legacy IPv6 ND protocol [RFC4861] has the following link model. All legacy IPv6 ND protocol [RFC4861] has the following link model. All
IPv6 nodes in the same on-link subnet, which use the same subnet IPv6 nodes in the same on-link subnet, which use the same subnet
prefix with on-link bit set, are reachable with each other by one-hop prefix with on-link bit set, are reachable with each other by one-hop
link. The symmetry of the connectivity among the nodes is preserved, link. The symmetry of the connectivity among the nodes is preserved,
that is, bidirectional connectivity among two on-link nodes. On the that is, bidirectional connectivity among two on-link nodes.
other hand, a link model in vehicular networks (called vehicular link However, a link model in vehicular networks (called vehicular link
model) should consider the asymmetry of the connectivity that model) should consider the asymmetry of the connectivity that
unidirectional links can exist due to interference in wireless unidirectional links can exist due to interference in wireless
channels and the different levels of transmission power in wireless channels and the different levels of transmission power in wireless
network interfaces. network interfaces.
The on-link subnet can be constructed by one link (as a basic service The on-link subnet can be constructed by one link (as a basic service
set) or multiple links (as an extended service set) called a multi- set) or multiple links (as an extended service set) called a multi-
link subnet [RFC6775]. In the legacy multi-link subnet, an all-node- link subnet [RFC6775]. In the legacy multi-link subnet, an all-node-
multicasted packet is copied and related to other links by an ND multicasted packet is copied and related to other links by an ND
proxy. On the other hand, in vehicular networks having fast moving proxy. On the other hand, in vehicular networks having fast moving
skipping to change at page 5, line 38 skipping to change at page 5, line 38
not need to reconfigure its IPv6 address during handover between not need to reconfigure its IPv6 address during handover between
those RSUs. However, the packet relay by an RSU as an ND proxy is those RSUs. However, the packet relay by an RSU as an ND proxy is
not required because such a relay can cause a broadcast storm in the not required because such a relay can cause a broadcast storm in the
extended subnet. Thus, in the multi-link subnet, all-node- extended subnet. Thus, in the multi-link subnet, all-node-
multicasting needs to be well-calibrated to either being confined to multicasting needs to be well-calibrated to either being confined to
multicasting in the current link or being disseminated to other links multicasting in the current link or being disseminated to other links
in the same subnet. in the same subnet.
In a connected multihop VANET, for the efficient communication, In a connected multihop VANET, for the efficient communication,
vehicles in the same link of an RSU can communicate directly with vehicles in the same link of an RSU can communicate directly with
each other, not through the relay of the RSU. This direct wireless each other, not through the serving RSU. This direct wireless
communication is similar to the direct wired communication in an on- communication is similar to the direct wired communication in an on-
link subnet using Ethernet as a wired network. The vehicular link link subnet using Ethernet as a wired network. The vehicular link
model needs to accommodate both the ad-hoc communication between model needs to accommodate both the ad-hoc communication between
vehicles and infrastructure communication between a vehicle and an vehicles and infrastructure communication between a vehicle and an
RSU in an efficient and flexible way. Therefore, the IPv6 ND should RSU in an efficient and flexible way. Therefore, the IPv6 ND should
be extended to accommodate the concept of a new IPv6 link model in be extended to accommodate the concept of a new IPv6 link model in
vehicular networks. vehicular networks.
To support multi-link subnet, this specification employs the Shared-
Prefix model for prefix assignments. Shared-Prefix model refer to an
addressing model where the prefix(es) are shared by more than one
node. In this document, we assume that in a specified subnet, all
interfaces of RSUs responding for prefix assignments to vehicles hold
same prefix, which ensure vehicles obtain and maintain same prefix in
this subnet scope.
4.2. ND Optimization 4.2. ND Optimization
This document takes advantage of the optimized ND for Low-Power This document takes advantage of the optimized ND for Low-Power
Wireless Personal Area Network (6LoWPAN) [RFC6775] because vehicular Wireless Personal Area Network (6LoWPAN) [RFC6775] because vehicular
environments have common parts with 6LoWPAN, such as the reduction of environments have common parts with 6LoWPAN, such as the reduction of
unnecessary wireless traffic by multicasting and the energy saving in unnecessary wireless traffic by multicasting and the energy saving in
battery. Note that vehicles tend to be electric vehicles whose battery. Note that vehicles tend to be electric vehicles whose
energy source is from their battery. energy source is from their battery.
In the optimized IPv6 ND for 6LoWPAN, the connections among nodes are In the optimized IPv6 ND for 6LoWPAN, the connections among nodes are
skipping to change at page 6, line 26 skipping to change at page 6, line 35
for vehicular networks along with new ND options (e.g., prefix for vehicular networks along with new ND options (e.g., prefix
discovery, service discovery, and mobility information options). discovery, service discovery, and mobility information options).
4.3. Design Goals 4.3. Design Goals
The vehicular ND in this document has the following design goals: The vehicular ND in this document has the following design goals:
o To perform prefix and service discovery through ND procedure; o To perform prefix and service discovery through ND procedure;
o To implement host-initiated refresh of Router Advertisement (RA) o To implement host-initiated refresh of Router Advertisement (RA)
and remove the need for routers to use periodic or unsolicited and remove the necessity for routers to use periodic or
multicast RA to find hosts; unsolicited multicast RA to find hosts;
o To create Neighbor Cache Entries (NCE) for all registered vehicles o To replace Neighbor Unreachable Detection(NUD), create Neighbor
in RSUs by adding Address Registration Option (ARO) in Neighbor Cache Entries (NCE) for all registered vehicles in RSUs and MA by
appending Address Registration Option (ARO) in Neighbor
Solicitation (NS), Neighbor Advertisement (NA) messages; Solicitation (NS), Neighbor Advertisement (NA) messages;
o To support a multihop DAD with two new ICMPv6 messages called o To support a multihop DAD with two new ICMPv6 messages called
Duplicate Address Request(DAR) and Duplicate Address Duplicate Address Request(DAR) and Duplicate Address
Confirmation(DAC) to eliminate multicast storm and save energy; Confirmation(DAC) to eliminate multicast storm and save energy;
and
o To support multi-hop communication for vehicles outside the
coverage of RSUs to communicate with the serving RSU via a relay
neighbor; and
o To provide a mobility management mechanism for seamless o To provide a mobility management mechanism for seamless
communication during a vehicle's travel in subnets via RSUs. communication during a vehicle's travel in subnets via RSUs.
5. Vehicular Network Architecture 5. Vehicular Network Architecture
This section describes a vehicular network architecture for V2V and This section describes a vehicular network architecture for V2V and
V2I communication. A vehicle and an RSU have their internal networks V2I communication. A vehicle and an RSU have their internal networks
having in-vehicle devices or servers, respectively. including in-vehicle devices or servers, respectively.
5.1. Vehicular Network 5.1. Vehicular Network
A vehicular network architecture for V2I and V2V is illustrated in A vehicular network architecture for V2I and V2V is illustrated in
Figure 1. Three RSUs are deployed along roadside and are connected Figure 1. Three RSUs are deployed along roadside and are connected
to an MA through wired links. There are two subnets such as Subnet1 to an MA through wired links. There are two subnets such as Subnet1
and Subnet2. The wireless links of RSU1 and RSU2 belong to the same and Subnet2. The wireless links of RSU1 and RSU2 belong to the same
subnet named Subnet1, but the wireless link of RSU3 belongs to subnet named Subnet1, but the wireless link of RSU3 belongs to
another subnet named Subnet2. Vehicle1 and Vehicle2 are wirelessly another subnet named Subnet2. Vehicle2 is wirelessly connected to
connected to RSU1 while Vehicle3 and Vehicle4 are connected to RSU2 RSU1 while Vehicle3 and Vehicle4 are connected to RSU2 and RSU3,
and RSU3, respectively. Vehicles can directly communicate with each respectively. Vehicles can directly communicate with each other
other through V2V connection (e.g., Vehicle1 and Vehicle2) to share through V2V connection (e.g., Vehicle1 and Vehicle2) to share driving
driving information. Vehicles are assumed to start the connection to information. In addition, vehicles not in range of any RSU may
an RSU when they entered the coverage of the RSU. connect with RSU in multi-hop connection via relay vehicle (e.g.,
Vehicle1 can contact RSU1 via Vehicle2). Vehicles are assumed to
start the connection to an RSU when they entered the coverage of the
RSU.
Traffic Control Center in Vehicular Cloud The document recommends a multi-link subnet involving multiple RSUs
*-----------------------------------------* as shown in Figure 1. This recommendation aims at the reduction of
* * the frequency with which vehicles have to change their IP address
* +----------------+ * during handover between two adjacent RSUs. To construct this multi-
* | Mobility Anchor| * link subnet, shared-prefix model is proposed. That is, for RSUs in
* +----------------+ * the same subnet, the interfaces responsible for prefix assignment for
* ^ * vehicles should hold the same prefix in their global address. This
* | * also promises vehicles achieve same prefix in this scope. When they
*--------------------v--------------------* pass through RSUs in the same subnet, vehicles do not need to perform
^ ^ ^ the Address Registration and DAD again because they can use their
| | | current IP address in the wireless coverage of the next RSU.
+------------------ | -------------|-------------+ +------------------+ Moreover, this proposal accord with the assumption that noes
| v v | | v | belonging to the same IP prefix are able to communicate with each
| +--------+ Ethernet +--------+ | | +--------+ | other directly. On the other hand, if vehicles enter the wireless
| | RSU1 |<----------->| RSU2 |<---------->| RSU3 | | coverage of an RSU belonging to another subnet with a different
| +--------+ +--------+ | | +--------+ | prefix, they repeat the Address Registration and DAD procedure to
| ^ ^ ^ | | ^ | update their IP address with the new prefix.
| : : : | | : |
| V2I : : V2I V2I : | | V2I : | Traffic Control Center in Vehicular Cloud
| v v v | | v | *-----------------------------------------*
| +--------+ +--------+ +--------+ | | +--------+ | * *
| |Vehicle1|===> |Vehicle2|===> |Vehicle3|===>| | |Vehicle4|===>| * +----------------+ *
| | |<....>| |<....>| | | | | | | * | Mobility Anchor| *
| +--------+ V2V +--------+ V2V +--------+ | | +--------+ | * +----------------+ *
| | | | * ^ *
+-------------------------------------------------+ +------------------+ * | *
*--------------------v--------------------*
^ ^ ^
| | |
| | |
v v v
+--------+ ethernet +--------+ +--------+
| RSU1 |<-------->| RSU2 |<---------->| RSU3 |
+--------+ +--------+ +--------+
^ ^ ^
: : :
+--------------------------------------+ +------------------+
| : V2I V2I : | | V2I : |
| v v | | v |
+--------+ | +--------+ +--------+ | | +--------+ |
|Vehicle1|=======>|Vehicle2|=========>|Vehicle3|====>| | |Vehicle4|===>|
| |<......>| |<........>| | | | | | |
+--------+ V2V +--------+ V2V +--------+ | | +--------+ |
| | | |
+--------------------------------------+ +------------------+
Subnet1 Subnet2 Subnet1 Subnet2
<----> Wired Link <....> Wireless Link ===> Moving Direction <----> Wired Link <....> Wireless Link ===> Moving Direction
Figure 1: A Vehicular Network Architecture for V2I and V2V Networking Figure 1: A Vehicular Network Architecture for V2I and V2V Networking
The document recommends a multi-link subnet involving multiple RSUs, In Figure 1, RSU1 and RSU2 are deployed in a multi-link subnet with
as shown in Figure 1. This recommendation aims at the reduction of the same prefix address in their interfaces responding for connection
the frequency with which vehicles have to change their IP address with vehicles. When vehicle2 leaves the coverage of RSU1 and enters
during handover between two adjacent RSUs. When they pass through RSU2, it maintains its address configuration and ignores Address
RSUs in the same subnet, vehicles do not need to perform the Address Registration and DAD steps. If vehicle2 moves into the coverage of
Registration and DAD again because they can use their current IP RSU3, since RSU3 belongs to another subnet and holds a different
address in the wireless coverage of the next RSU, belonging to the prefix from RSU1 and RSU2, so vehicle2 must do Address Registration
same subnet. On the other hand, if they enter the wireless coverage and DAD just as connecting to a new RSU. Note that vehicles and RSUs
of an RSU belonging to another subnet with a different prefix, have their internal networks including in-vehicle devices and
vehicles repeat the Address Registration and DAD procedure to update servers, respectively. The structures of the internal networks are
their IP address with the new prefix. described in [IPWAVE-PS].
In Figure 1, RSU1 and RSU2 are deployed in the a multi-link subnet 5.2. V2I Internetworking
with the same prefix in their address. When vehicle1 leaves the
coverage of RSU1 and enters RSU2, it maintains its address and This subsection explains V2I internteworking between vehicle network
ignores Address Registration and DAD steps. If vehicle1 moves into and RSU network where vehicle network is an internal network in a
the coverage of RSU3, since RSU3 belongs to another subnet and holds vehicle, and RSU network is an internal network in an RSU, as shown
a different prefix from RSU1 and RSU2, so vehicles must do Address in Figure 2.
Registration and DAD just as connecting to a new RSU. Note that
vehicles and RSUs have their internal networks having in-vehicle
devices and servers, respectively. The structures of the internal
networks are described in [IPWAVE-PS].
+-----------------+ +-----------------+
(*)<........>(*) +----->| Vehicular Cloud | (*)<........>(*) +----->| Vehicular Cloud |
2001:DB8:1:1::/64 | | | +-----------------+ 2001:DB8:1:1::/64 | | | +-----------------+
+------------------------------+ +---------------------------------+ +------------------------------+ +---------------------------------+
| v | | v v | | v | | v v |
| +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ |
| | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | | | | Host1 | |RDNSS1| |Router1| | | |Router3| |RDNSS2| | Host3 | |
| +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ | | +-------+ +------+ +-------+ |
| ^ ^ ^ | | ^ ^ ^ | | ^ ^ ^ | | ^ ^ ^ |
skipping to change at page 9, line 5 skipping to change at page 9, line 42
| v v | | v v v | | v v | | v v v |
| ---------------------------- | | ------------------------------- | | ---------------------------- | | ------------------------------- |
| 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 | | 2001:DB8:10:2::/64 | | 2001:DB8:20:2::/64 |
+------------------------------+ +---------------------------------+ +------------------------------+ +---------------------------------+
Vehicle1 (Moving Network1) RSU1 (Fixed Network1) Vehicle1 (Moving Network1) RSU1 (Fixed Network1)
<----> Wired Link <....> Wireless Link (*) Antenna <----> Wired Link <....> Wireless Link (*) Antenna
Figure 2: Internetworking between Vehicle Network and RSU Network Figure 2: Internetworking between Vehicle Network and RSU Network
5.2. V2I Internetworking
This subsection explains V2I internteworking between vehicle network
and RSU network where vehicle network is an internal network in a
vehicle, and RSU network is an internal network in an RSU, as shown
in Figure 2.
Figure 2 shows the V2I networking of a vehicle and an RSU whose Figure 2 shows the V2I networking of a vehicle and an RSU whose
internal networks are Moving Network1 and Fixed Network1, internal networks are Moving Network1 and Fixed Network1,
respectively. Vehicle1 has the DNS Server (RDNSS1), the two hosts respectively. Vehicle1 has the DNS Server (RDNSS1), the two hosts
(Host1 and Host2), and the two routers (Router1 and Router2). RSU1 (Host1 and Host2), and the two routers (Router1 and Router2). RSU1
has the DNS Server (RDNSS3), one host (Host5), the two routers has the DNS Server (RDNSS3), one host (Host5), the two routers
(Router5 and Router6). (Router5 and Router6).
It is assumed that RSU1 has a collection of servers (Server1 to It is assumed that RSU1 has a collection of servers (Server1 to
ServerN) for various services in the road networks, such as road ServerN) for various services in the road networks, such as road
emergency notification and navigation services. Vehicle1's Router1 emergency notification and navigation services. Vehicle1's Router1
skipping to change at page 14, line 50 skipping to change at page 15, line 28
prefixes and services of the other party without any additional prefixes and services of the other party without any additional
service discovery protocol. service discovery protocol.
6.5. Message Exchange Procedure for V2I Networking 6.5. Message Exchange Procedure for V2I Networking
This subsection explains a message exchange procedure for vehicular This subsection explains a message exchange procedure for vehicular
neighbor discovery in V2I networking, where a vehicle communicates neighbor discovery in V2I networking, where a vehicle communicates
with its correponding node in the Internet via an RSU. with its correponding node in the Internet via an RSU.
Figure 7 shows an example of message exchange procedure in V2I Figure 7 shows an example of message exchange procedure in V2I
networkging. The detailed steps of the procedure are explained in networking. Detailed steps of the procedure are explained in
Section 7 and Section 8. Section 7 and Section 8.
Note that a vehicle could also perform the prefix and service
discovery simultaneously along with Address Registration procedure,
as shown in Figure 9.
This document specified that RSUs as routers do not transmit
periodical and unsolicited multicast RA messages including a prefix
for energy saving in vehicular networks. Vehicles as hosts
periodically initiate an RS message according to a time interval
(considering its position and an RSU's coverage). Since they have a
digital road map with the information of RSUs (e.g., position and
communication coverage), vehicles can know when they will go out of
the communication range of an RSU along with the signal strength
(e.g., Received Channel Power Indicator (RCPI) [VIP-WAVE]) from the
RSU. RSUs replies with a solicited RA in unicast only when they
receive an RS message.
Vehicle RSU Mobility Anchor Vehicle RSU Mobility Anchor
| | | | | |
|-RS with Mobility Info->| | |-RS with Mobility Info->| |
| [VMI] | | | [VMI] | |
| | | | | |
| |--------PBU------>| | |--------PBU------>|
| | | | | |
| | | | | |
| |<-------PBA-------| | |<-------PBA-------|
| | | | | |
skipping to change at page 15, line 37 skipping to change at page 16, line 37
| | | | | |
| | | | | |
| |<-------DAC-------| | |<-------DAC-------|
| | | | | |
| | | | | |
|<--NA with Address Reg--| | |<--NA with Address Reg--| |
| [ARO+VPI+VSI] | | | [ARO+VPI+VSI] | |
Figure 7: Message Interaction for Vehicular Neighbor Discovery Figure 7: Message Interaction for Vehicular Neighbor Discovery
Note that a vehicle could also perform the prefix and service
discovery simultaneously along with Address Registration procedure,
as shown in Figure 9.
Note that RSUs as routers do not transmit periodical and unsolicited
multicast RA messages including a prefix for energy saving in
vehicular networks. Vehicles as hosts periodically initiate an RS
message according to a time interval (considering its position and an
RSU's coverage). Note that since they have a digital road map with
the information of RSUs (e.g., position and communication coverage),
vehicles can know when they will go out of the communication range of
an RSU along with the signal strength (e.g., Received Channel Power
Indicator (RCPI) [VIP-WAVE]) from the RSU. RSUs replies with a
solicited RA in unicast only when they receive an RS message.
7. Address Registration and Duplicate Address Detection 7. Address Registration and Duplicate Address Detection
This section explains address configuration, consisting of IP Address This section explains address configuration, consisting of IP Address
Autoconfiguration, Address Registration, and multihop DAD. Autoconfiguration, Address Registration, and multihop DAD via V2I or
V2V.
This document recommends a new Address Registration and DAD scheme in This document recommends a new Address Registration and DAD scheme in
order to avoid multicast flooding and decrease link-scope multicast order to avoid multicast flooding and decrease link-scope multicast
for energy and wireless channel conservation on a large-scale for energy and wireless channel conservation on a large-scale
vehicular network. Host-initiated refresh of RA removes the need for vehicular network. Host-initiated refresh of RA removes the
routers to use periodic and unsolicited multicast RAs to accommodate necessity for routers to use frequent and unsolicited multicast RAs
hosts. This also enables the same IPv6 address prefix(es) to be used to accommodate hosts. This also enables the same IPv6 address
across a subnet. prefix(es) to be used across a subnet.
There are two scenarios about Address Registration part. If they There are three scenarios feasible in Address Registration scheme:
have already configured their IP addresses with the prefix obtained
from the previous RSU, and the current RSU located in the same subnet 1. Vehicle enters the subnet for the first time or the current RSU
as the previous RSU, which means that they have the same prefix, then belongs to another subnet: Vehicles need to perform the Address
vehicles have no need to repeat the Address Registration and multihop Registration and multihop DAD in the following subsections.
DAD. However, if the current RSU belongs to another subnet, vehicles
need to perform the Address Registration and multihop DAD in the 2. Vehicle has already configured its IP addresses with prefix
following subsections. obtained from the previous RSU, and the current RSU located in
the same subnet: This means RSUs have the same prefix and the
vehicle has no need to repeat the Address Registration and
multihop DAD.
3. Vehicle is not in the coverage of RSU but has a neighbor
registered in RSU: This document proposes a new V2V scenario for
vehicles which are currently not in the range of the RSU. If a
user vehicle failed to find an on-link RSU, it starts to look for
adjacent vehicle neighbors which can work as relay neighbor to
share the prefix obtained from RSU and undertake the DAD of the
user vehicle by forwarding DAD messages to RSU.
7.1. Address Autoconfiguration 7.1. Address Autoconfiguration
A vehicle as an IPv6 host creates its link-local IPv6 address and A vehicle as an IPv6 host creates its link-local IPv6 address and
global IPv6 address as follows [RFC4862]. When they receive RS global IPv6 address as follows [RFC4862]. When they receive RS
messages from vehicles, RSUs send back RA messages containing prefix messages from vehicles, RSUs send back RA messages containing prefix
information. The vehicle makes its global IPv6 addresses by information. The vehicle makes its global IPv6 addresses by
combining the prefix for its current link and its link-layer address. combining the prefix for its current link and its link-layer address.
The address autoconfiguration does not perform the legacy DAD as The address autoconfiguration does not perform the legacy DAD as
skipping to change at page 16, line 47 skipping to change at page 17, line 43
Section 7.3. Section 7.3.
7.2. Address Registration 7.2. Address Registration
After its IP tentative address autoconfiguration with the known After its IP tentative address autoconfiguration with the known
prefix from an RSU and its link-layer address, a vehicle starts to prefix from an RSU and its link-layer address, a vehicle starts to
register its IP address to the serving RSU along with multihop DAD. register its IP address to the serving RSU along with multihop DAD.
Address Register Option (ARO) is used in this step and its format is Address Register Option (ARO) is used in this step and its format is
defined in [RFC6775]. defined in [RFC6775].
ARO is always host-initiated by vehicles. The information contained ARO is always host-initiated by vehicles. Information such as
in ARO becomes included in multihop Duplicate Address Request (DAR) registration time and registration status contained in ARO is also
and Duplicate Address Confirmation (DAC) messages used between RSU included in multihop Duplicate Address Request (DAR) and Duplicate
and MA, but ARO is not directly used in these two messages. Address Confirmation (DAC) messages used between RSU and MA, but ARO
is not directly used in these two messages.
An example message exchange procedure of Address Registration is An example message exchange procedure of Address Registration is
presented in Figure 8. Since Address Registration is performed presented in Figure 8. Since Address Registration is performed
simultaneously with the multihop DAD, the specific procedure is simultaneously with the multihop DAD, the specific procedure is
together described with the DAD mechanism in Section 7.3. together described with the DAD mechanism in Section 7.3.
Vehicle RSU Vehicle RSU
| | | |
| | | |
1. |----NS with Address Reg--->| 1. |----NS with Address Reg--->|
skipping to change at page 19, line 10 skipping to change at page 20, line 10
registration vehicle to notify the registration failure. registration vehicle to notify the registration failure.
Otherwise, the RSU changes the tentative NCE into a registered Otherwise, the RSU changes the tentative NCE into a registered
NCE in its Neighbor Cache, and then send back an NS to the NCE in its Neighbor Cache, and then send back an NS to the
vehicle to notify the registration success. vehicle to notify the registration success.
Thus, the multihop DAD is processed simultaneously with the Address Thus, the multihop DAD is processed simultaneously with the Address
Registration. Note that the tentative address is not considered Registration. Note that the tentative address is not considered
assigned to the vehicle until the MA confirms the uniqueness of the assigned to the vehicle until the MA confirms the uniqueness of the
register-requested address in the multihop DAD. register-requested address in the multihop DAD.
User Vehicle Relay Vehicle RSU Mobility Anchor
| | | |
|------------------------| | |
| RD failed | | |
|------------------------| | |
| | | |
| | | |
|-----------NS---------->| | |
| | | |
|<--NA with Prefix Info--| | |
| | | |
| | | |
|--NS with Address Reg-->| | |
| [ARO+VPI+VSI] | | |
| |----- Forward NS ----->| |
| | | |
| | |-----------------|
| | | Same as Figure 9|
| | |-----------------|
| | | |
| |<--NA with Address Reg-| |
| | [ARO+VPI+VSI] | |
|<------ Forward NA -----| | |
| | | |
Figure 10: Address Registration and Multihop DAD via V2V Relay
If a vehicle failed to register a default router, it triggers
neighbor discovery to look for vehicle neighbors which can provide
relay service using multi-hop communication. In this specification,
we assumed vehicles would not emulate V2V communication and trigger
relay scenario only if Router Discovery(RD) failed. On the other
hand, at most one intermediate vehicle acts as a relay for another
vehicle to communicate with the RSU.
Since vehicles have a digital road map with the information of RSUs
(e.g., position and communication coverage), they can determine if
they are available to serve as relay vehicle. Only vehicles with
ability to serve as temporary relays will take action when they
receive relay service requests. The user vehicle can process global
address configuration, Address Registration and DAD through relay
vehicle before it enters the coverage of RSUs. See Figure 10.
When a user vehicle failed to directly register with a RSU, it
initiates neighbor discovery to detect vehicle neighbors through V2V
communication. Vehicle sends NS messages to connect with neighbors
in range. If neighbor can provide relay service, it creates a NCE
for user vehicle, setting its own address as relay address, and sends
back NA with prefix information received from RSU.
With receipt of NA, user vehicle configures its global address with
prefix information as mentioned in Section 7.1. After this, user
vehicle takes up to initiate the Address Registration along with DAD
process via relay vehicle. NS message is configured as specified in
Section 7.2 but indicate the relay vehicle's address as next-hop for
reaching the RSU. In such a case, when relay vehicle receives relay
request message, it will forward NS message to RSU. The procedure
set up on the rails except MA will include the relay vehicle's
address as relay address in NCE to indicate that at this moment it is
not a directly attached vehicle, and set the relay address as next-
hop address. Relay vehicle forwards DAD result information message
to user vehicle as soon as it received.
7.4. Pseudonym Handling 7.4. Pseudonym Handling
Considering the privacy protection of a vehicle, a pseudonym Considering the privacy protection of a vehicle, a pseudonym
mechanism for its link-layer address is requested. This mechanism mechanism for its link-layer address is requested. This mechanism
periodically modifies the link-layer address, leading to the update periodically modifies the link-layer address, leading to the update
of the corresponding IP address. A random MAC Address Generation of the corresponding IP address. A random MAC Address Generation
mechanism is proposed in Appendix F.4 of [IEEE-802.11-OCB] by mechanism is proposed in Appendix F.4 of [IEEE-802.11-OCB] by
generating the 46 remaining bits of MAC address using a random number generating the 46 remaining bits of MAC address using a random number
generator. When it changes its MAC address, a vehicle should ask the generator. When it changes its MAC address, a vehicle should ask the
serving RSU to update its own NCE, and to register its IP address serving RSU to update its own NCE, and to register its IP address
into the MA again. into the MA again.
8. Mobility Management
A mobility management is required for the seamless communication of
vehicles moving between the RSUs. When a vehicle moves into the
coverage of another RSU, a different IP address is assigned to the
vehicle, resulting in the reconfiguration of transport-layer session
information (i.e., end-point IP address) to avoid service disruption.
Considering this issue, this document proposes a handover mechanism
for seamless communication.
Vehicle RSU Mobility Anchor Vehicle RSU Mobility Anchor
| | | | | |
|-RS with Mobility Info->| | |-RS with Mobility Info->| |
| [VMI] | | | [VMI] | |
| | | | | |
| |--------PBU------>| | |--------PBU------>|
| | | | | |
| | | | | |
| |<-------PBA-------| | |<-------PBA-------|
| | | | | |
| | | | | |
| |===Bi-Dir Tunnel==| | |===Bi-Dir Tunnel==|
| | | | | |
| | | | | |
|<----RA with prefix-----| | |<----RA with prefix-----| |
| | | | | |
Figure 10: Message Interaction for Vehicle Attachment Figure 11: Message Interaction for Vehicle Attachment
8. Mobility Management
A mobility management is required for the seamless communication of
vehicles moving between the RSUs. When a vehicle moves into the
coverage of another RSU, a different IP address is assigned to the
vehicle, resulting in the reconfiguration of transport-layer session
information (i.e., end-point IP address) to avoid service disruption.
Considering this issue, this document proposes a handover mechanism
for seamless communication.
In [VIP-WAVE], the authors constructed a network-based mobility In [VIP-WAVE], the authors constructed a network-based mobility
management scheme using Proxy Mobile IPv6 (PMIPv6) [RFC5213], which management scheme using Proxy Mobile IPv6 (PMIPv6) [RFC5213], which
is highly suitable to vehicular networks. This document uses a is highly suitable to vehicular networks. This document uses a
mobility management procedure similar to PMIPv6 along with prefix mobility management procedure similar to PMIPv6 along with prefix
discovery. discovery.
Figure 11 shows the binding update flow when a vehicle entered the
subnet of an RSU. RSUs act as Mobility Anchor Gateway (MAG) defined
in [VIP-WAVE]. When it receives RS messages from a vehicle
containing its mobility information (e.g., position, speed, and
direction), an RSU sends its MA a Proxy Binding Update (PBU) message
[RFC5213][RFC3775], which contains a Mobility Option for the
vehicle's mobility information. The MA receives the PBU and sets up
a Binding Cache Entry (BCE) as well as a bi-directional tunnel
(denoted as Bi-Dir Tunnel in Figure 11) between the serving RSU and
itself. Through this tunnel, all traffic packets to the vehicle are
encapsulated toward the RSU. Simultaneously, the MA sends back a
Proxy Binding Acknowledgment (PBA) message to the serving RSU. This
serving RSU receives the PBA and sets up a bi-directional tunnel with
the MA. After this binding update, the RSU sends back an RA message
to the vehicle including its own prefix for the address
autoconfiguration.
Vehicle c-RSU Mobility Anchor n-RSU Vehicle c-RSU Mobility Anchor n-RSU
| | | | | | | |
| |===Bi-Dir Tunnel==| | | |===Bi-Dir Tunnel==| |
| | | | | | | |
| | | | | | | |
| |----DeReg PBU---->| | | |----DeReg PBU---->| |
| | | | | | | |
| | | | | | | |
| |<-------PBA-------| | | |<-------PBA-------| |
| | | | | | | |
skipping to change at page 20, line 34 skipping to change at page 23, line 28
| | | | | | | |
|---------------------------RS-------------------------->| |---------------------------RS-------------------------->|
| | | |
| Registration step as shown in Figure 5 | | Registration step as shown in Figure 5 |
| | | |
| | |===Bi-Dir Tunnel==| | | |===Bi-Dir Tunnel==|
| | | |
|<--------------------------RA---------------------------| |<--------------------------RA---------------------------|
| | | |
Figure 11: Message Interaction for Vehicle Handoff Figure 12: Message Interaction for Vehicle Handoff
Figure 10 shows the binding update flow when a vehicle entered the
subnet of an RSU. RSUs act as Mobility Anchor Gateway (MAG) defined
in [VIP-WAVE]. When it receives RS messages from a vehicle
containing its mobility information (e.g., position, speed, and
direction), an RSU sends its MA a Proxy Binding Update (PBU) message
[RFC5213][RFC3775], which contains a Mobility Option for the
vehicle's mobility information. The MA receives the PBU and sets up
a Binding Cache Entry (BCE) as well as a bi-directional tunnel
(denoted as Bi-Dir Tunnel in Figure 10) between the serving RSU and
itself. Through this tunnel, all traffic packets to the vehicle are
encapsulated toward the RSU. Simultaneously, the MA sends back a
Proxy Binding Acknowledgment (PBA) message to the serving RSU. This
serving RSU receives the PBA and sets up a bi-directional tunnel with
the MA. After this binding update, the RSU sends back an RA message
to the vehicle including its own prefix for the address
autoconfiguration.
When the vehicle changes its location, the MA has to change the end- When the vehicle changes its location, the MA has to change the end-
point of the tunnel for the vehicle into the new RSU's IP address. point of the tunnel for the vehicle into the new RSU's IP address.
As shown in Figure 11, when the MA receives a new PBU from the new As shown in Figure 12, when the MA receives a new PBU from the new
RSU, it changes the tunnel's end-point from the current RSU (c-RSU) RSU, it changes the tunnel's end-point from the current RSU (c-RSU)
to the new RSU (n-RSU). If there is ongoing IP packets toward the to the new RSU (n-RSU). If there is ongoing IP packets toward the
vehicle, the MA encapsulates the packets and then forwards them vehicle, the MA encapsulates the packets and then forwards them
towards the new RSU. Through this network-based mobility management, towards n-RSU. Through this network-based mobility management, the
the vehicle is not aware of any changes at its network layer and can vehicle is not aware of any changes at its network layer and can
maintain its transport-layer sessions without any disruption. maintain its transport-layer sessions without any disruption.
If c-RSU and n-RSU are adjacent, that is, vehicles are moving in
specified routes with fixed RSU allocation, the procedure can be
simplified by constructing bidirectional tunnel directly between them
(cancel the intervention of MA) to alleviate the traffic flow in MA
as well as reduce handover delay. See Figure 13.
Vehicle c-RSU n-RSU
| | |
|---------------------| |
|c-RSU detects leaving| |
|---------------------| |
| |--------PBU------>|
| | |
| |===Bi-Dir Tunnel==|
| | |
| |<-------PBA-------|
| | |
| | |
|(-------------------RS---------------->)|
| |
| |
|<-------------------RA------------------|
| |
Figure 13: Vehicle Handoff between Adjacent RSUs
Since RSUs are in charge of detecting when a node joins or moves
through its domain, if c-RSU detects the vehicle is going to leave
its coverage and enter the area of adjacent RSU, it sends a PBU
message to inform n-RSU about the handover of vehicle and update its
mobility information. n-RSU receives the request and construct a
bidirectional tunnel between c-RSU and itself, then send back PBA
message for acknowledgment. If there are ongoing IP packets, c-RSU
encapsulates the packets and then forwards them to n-RSU. When n-RSU
detects the entrance of the vehicle, it directly sends RA mesage to
vehicle for connection establishment (or replies solicited RA if
vehicle sends request RS message first).
9. Security Considerations 9. Security Considerations
This document shares all the security issues of the neighbor This document shares all the security issues of the neighbor
discovery protocol and 6LoWPAN protocol. This document can get discovery protocol and 6LoWPAN protocol. This document can get
benefits from secure neighbor discovery (SEND) [RFC3971] in order to benefits from secure neighbor discovery (SEND) [RFC3971] in order to
protect ND from possible security attacks. protect ND from possible security attacks.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 22, line 22 skipping to change at page 25, line 42
10.2. Informative References 10.2. Informative References
[DSRC-WAVE] [DSRC-WAVE]
Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its
Architecture, Design, and Characteristics", Architecture, Design, and Characteristics",
IEEE Communications Surveys & Tutorials, 12(4), 2012. IEEE Communications Surveys & Tutorials, 12(4), 2012.
[ID-DNSNA] [ID-DNSNA]
Jeong, J., Ed., Lee, S., and J. Park, "DNS Name Jeong, J., Ed., Lee, S., and J. Park, "DNS Name
Autoconfiguration for Internet of Things Devices", draft- Autoconfiguration for Internet of Things Devices", draft-
jeong-ipwave-iot-dns-autoconf-04 (work in progress), jeong-ipwave-iot-dns-autoconf-05 (work in progress), March
October 2018. 2019.
[IEEE-802.11-OCB] [IEEE-802.11-OCB]
IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium "Part 11: Wireless LAN Medium Access Control (MAC) and
Access Control (MAC) and Physical Layer (PHY) Physical Layer (PHY) Specifications", IEEE Std
Specifications", IEEE Std 802.11-2016, December 2016. 802.11-2016, December 2016.
[IEEE-802.11p] [IEEE-802.11p]
IEEE Std 802.11p, "Part 11: Wireless LAN Medium Access "Part 11: Wireless LAN Medium Access Control (MAC) and
Control (MAC) and Physical Layer (PHY) Specifications Physical Layer (PHY) Specifications Amendment 6: Wireless
Amendment 6: Wireless Access in Vehicular Environments", Access in Vehicular Environments", June 2010.
June 2010.
[IPWAVE-PS] [IPWAVE-PS]
Jeong, J., Ed., "IP Wireless Access in Vehicular Jeong, J., Ed., "IP Wireless Access in Vehicular
Environments (IPWAVE): Problem Statement and Use Cases", Environments (IPWAVE): Problem Statement and Use Cases",
draft-ietf-ipwave-vehicular-networking-07 (work in draft-ietf-ipwave-vehicular-networking-08 (work in
progress), November 2018. progress), March 2019.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, February 2013.
[VIP-WAVE] [VIP-WAVE]
Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the
Feasibility of IP Communications in 802.11p Vehicular Feasibility of IP Communications in 802.11p Vehicular
skipping to change at page 24, line 6 skipping to change at page 27, line 6
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-jeong-ipwave-vehicular-neighbor- Appendix A. Changes from draft-jeong-ipwave-vehicular-neighbor-
discovery-04 discovery-05
The following changes are made from draft-jeong-ipwave-vehicular- The following changes are made from draft-jeong-ipwave-vehicular-
neighbor-discovery-04: neighbor-discovery-05:
o This version includes the contents of the IPv6 vehicular neighbor o In Section 4.1, a Shared-Prefix model is introduced for prefix
discovery in draft-xiang-ipwave-vehicular-neighbor-discovery-00 assignment specified in this document.
for IP-based vehicular networks.
o In Section 6.3, a Vehicular Mobility Information (VMI) option is o In Section 4.3, design goals are refined including the
defined to report the mobility information of a vehicle or an RSU. cancellation of Neighbor Unreachable Detection, and also the
support of multi-hop communication for vehicles not in the
coverage of RSUs.
o In Section 5.1, the Vehicular Network Architecture is updated on
subnet division and V2V communication.
o In Section 7, a new scenario is added to facilitate vehicles
outside the coverage of RSU to do Address Registration and DAD via
relay vehicle.
o In Section 8, a simplified mobility management in vehicle handoff
for adjacent RSUs is supplemented based on the original proposal.
Appendix B. Acknowledgments Appendix B. Acknowledgments
This work was supported by Basic Science Research Program through the This work was supported by Basic Science Research Program through the
National Research Foundation of Korea (NRF) funded by the Ministry of National Research Foundation of Korea (NRF) funded by the Ministry of
Education (2017R1D1A1B03035885). Education (2017R1D1A1B03035885).
This work was supported in part by Global Research Laboratory Program This work was supported in part by Global Research Laboratory Program
through the NRF funded by the Ministry of Science and ICT (MSIT) through the NRF funded by the Ministry of Science and ICT (MSIT)
(NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT
 End of changes. 49 change blocks. 
188 lines changed or deleted 336 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/