< draft-jeong-ipwave-vehicular-mobility-management-00.txt   draft-jeong-ipwave-vehicular-mobility-management-01.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: September 29, 2019 Sungkyunkwan University Expires: January 9, 2020 Sungkyunkwan University
March 28, 2019 July 8, 2019
Vehicular Mobility Management for IP-Based Vehicular Networks Vehicular Mobility Management for IP-Based Vehicular Networks
draft-jeong-ipwave-vehicular-mobility-management-00 draft-jeong-ipwave-vehicular-mobility-management-01
Abstract Abstract
This document specifies a vehicular mobility management scheme for This document specifies a Vehicular Mobility Management (VMM) scheme
IP-based vehicular networks. The vehicular mobility management for IP-based vehicular networks. The VMM scheme takes advantage of a
scheme takes advantage of a vehicular link model based on a multi- vehicular link model based on a multi-link subnet. With a vehicle's
link subnet. With a vehicle's mobility information (e.g., position, mobility information (e.g., position, speed, and direction) and
speed, and direction) and navigation path (i.e., trajectory), it can navigation path (i.e., trajectory), it can provide a moving vehicle
provide a moving vehicle with proactive and seamless handoff along with proactive and seamless handoff along with its trajectory.
with its trajectory.
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 September 29, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 23 skipping to change at page 2, line 22
4. Vehicular Network Architecture . . . . . . . . . . . . . . . 4 4. Vehicular Network Architecture . . . . . . . . . . . . . . . 4
4.1. Vehicular Network . . . . . . . . . . . . . . . . . . . . 4 4.1. Vehicular Network . . . . . . . . . . . . . . . . . . . . 4
5. Mobility Management . . . . . . . . . . . . . . . . . . . . . 6 5. Mobility Management . . . . . . . . . . . . . . . . . . . . . 6
5.1. Network Attachment of a Vehicle . . . . . . . . . . . . . 6 5.1. Network Attachment of a Vehicle . . . . . . . . . . . . . 6
5.2. Handoff within One Prefix Domain . . . . . . . . . . . . 8 5.2. Handoff within One Prefix Domain . . . . . . . . . . . . 8
5.3. Handoff between Multiple Prefix Domains . . . . . . . . . 10 5.3. Handoff between Multiple Prefix Domains . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 Appendix A. Changes from draft-jeong-ipwave-vehicular-mobility-
management-00 . . . . . . . . . . . . . . . . . . . 14
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document proposes a mobility management scheme for IP-based This document proposes a mobility management scheme for IP-based
vehicular networks, which is called vehicular mobility management vehicular networks, which is called Vehicular Mobility Management
(VMM). This vehicular mobility management is tailored for a (VMM). The VMM is tailored for a vehicular network architecture and
vehicular network architecture and a vehicular link model described a vehicular link model described in the IPWAVE problem statement
in IPWAVE problem statement document [I-D.IPWAVE-PS]. document [I-D.IPWAVE-PS].
To support the interaction between vehicles or between vehicles and To support the interaction between vehicles or between vehicles and
Rode-Side Units (RSUs), Vehicular Neighbor Discovery (VND) is Rode-Side Units (RSUs), Vehicular Neighbor Discovery (VND) is
proposed as an enhanced IPv6 Neighbor Discovery (ND) for IP-based proposed as an enhanced IPv6 Neighbor Discovery (ND) for IP-based
vehicular networks [I-D.IPWAVE-VND]. For an efficient IPv6 Stateless vehicular networks [I-D.IPWAVE-VND]. For an efficient IPv6 Stateless
Address Autoconfiguration (SLAAC) [RFC4862], VND adopts an optimized Address Autoconfiguration (SLAAC) [RFC4862], VND adopts an optimized
Address Registration using a multihop Duplicate Address Detection Address Registration using a multihop Duplicate Address Detection
(DAD). This multihop DAD enables a vehicle to have a unique IP (DAD). This multihop DAD enables a vehicle to have a unique IP
address in a multi-link subnet that consists of multiple wireless address in a multi-link subnet that consists of multiple wireless
subnets with the same IP prefix, which corresponds to wireless subnets with the same IP prefix, which corresponds to wireless
coverage of multiple Road-Side Units (RSUs). Also, VND supports IP coverage of multiple RSUs. Also, VND supports IP packet routing via
packet routing via a connected Vehicular Ad Hoc Network (VANET) by a connected Vehicular Ad Hoc Network (VANET) by letting vehicles
letting vehicles exchange the prefixes of their internal networks exchange the prefixes of their internal networks through their
through their external wireless interface. external wireless interface.
The mobility management in this multi-link subnet needs a new The mobility management in this multi-link subnet needs a new
approach from the legacy mobility management schemes. This document approach from legacy mobility management schemes. This document aims
aims at an efficient mobility management scheme called vehicular at an efficient mobility management scheme called VMM to support
mobility management called VMM to support efficient V2V, V2I, and V2X efficient V2V, V2I, and V2X communications in a road network. The
communications in a road network. The VMM takes advantage of the VMM takes advantage of the mobility information (e.g., a vehicle's
mobility information (e.g., a vehicle's speed, direction, and speed, direction, and position) and trajectory (i.e., navigation
position) and trajectory (i.e., navigation path) of each vehicle path) of each vehicle registered into a Traffic Control Center (TCC)
registered into a Traffic Control Center (TCC) in the vehicular in the vehicular cloud.
cloud.
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
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology 3. Terminology
This document uses the terminology described in [RFC4861] and This document uses the terminology described in [RFC4861] and
skipping to change at page 4, line 24 skipping to change at page 4, line 24
4. Vehicular Network Architecture 4. 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
including in-vehicle devices or servers, respectively. including in-vehicle devices or servers, respectively.
4.1. Vehicular Network 4.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. In this figure, there is a vehicular cloud having a Figure 1. In this figure, there is a vehicular cloud having a TCC.
Traffic Control Center (TCC). The TCC has Mobility Anchors (MAs) for The TCC has Mobility Anchors (MAs) for the mobility management of
the mobility management of vehicles under its control. Each MA is in vehicles under its control. Each MA is in charge of the mobility
charge of the mobility management of vehicles under its prefix management of vehicles under its prefix domain, which is a multi-link
domain, which is a multi-link subnet of RSUs sharing the same prefix subnet of RSUs sharing the same prefix [I-D.IPWAVE-PS]. A vehicular
[I-D.IPWAVE-PS]. A vehicular network is a wireless network network is a wireless network consisting of RSUs and vehicles. RSUs
consisting of RSUs and vehicles. RSUs are interconnected with each are interconnected with each other through a wired network, and
other through a wired network, and vehicles can construct Vehicular vehicles can construct VANETs via V2V and V2I communications.
Ad Hoc Networks (VANET).
*-----------------------------------------* *-----------------------------------------*
* TCC in Vehicular Cloud * * TCC in Vehicular Cloud *
* +-------------------------------------+ * * +-------------------------------------+ *
+--------+ * | +---------+ +---------+ | * +--------+ * | +---------+ +---------+ | *
| CN1 |<---->* | | MA1 |<------->| MA2 | | * | CN1 |<---->* | | MA1 |<------->| MA2 | | *
+--------+ * | +---------+ +---------+ | * +--------+ * | +---------+ +---------+ | *
* +-------------------------------------+ * * +-------------------------------------+ *
* ^ ^ * * ^ ^ *
* | INTERNET | * * | INTERNET | *
skipping to change at page 5, line 28 skipping to change at page 5, line 28
v v v v v v
+--------+ Ethernet +--------+ Ethernet +--------+ +--------+ Ethernet +--------+ Ethernet +--------+
| RSU1 |<-------->| RSU2 |<-------->| RSU3 | | RSU1 |<-------->| RSU2 |<-------->| RSU3 |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
^ ^ ^ ^ ^ ^
: : : : : :
+-----------------------------------+ +-----------------+ +-----------------------------------+ +-----------------+
| : V2I V2I : | | V2I : | | : V2I V2I : | | V2I : |
| v v | | v | | v v | | v |
+--------+ | +--------+ +--------+ | | +--------+ | +--------+ | +--------+ +--------+ | | +--------+ |
|Vehicle1|======>|Vehicle2|======>|Vehicle3|====>| | |Vehicle4|====>| |Vehicle1|===> |Vehicle2|===> |Vehicle3|===> | | |Vehicle4|===> |
| |<.....>| |<.....>| | | | | | | | |<.....>| |<.....>| | | | | | |
+--------+ V2V +--------+ V2V +--------+ | | +--------+ | +--------+ 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
In Figure 1, three RSUs are deployed either at intersections or along In Figure 1, three RSUs are deployed either at intersections or along
roadways. They are connected to an MA through wired networks. In roadways. They are connected to an MA through wired networks. In
the vehicular network, there are two subnets such as Subnet1 and the vehicular network, there are two subnets such as Subnet1 and
Subnet2. Subnet1 is a multi-link subnet consisting of multiple Subnet2. Subnet1 is a multi-link subnet consisting of multiple
wireless coverage areas of multiple RSUs, and those areas share the wireless coverage areas of multiple RSUs, and those areas share the
same IPv6 prefix to construct a single logical subnet same IPv6 prefix to construct a single logical subnet
[I-D.IPWAVE-PS]. That is, the wireless links of RSU1 and RSU2 belong [I-D.IPWAVE-PS]. That is, the wireless links of RSU1 and RSU2 belong
to Subnet1. Thus, since Vehicle2 and Vehicle2 use the same prefix to Subnet1. Thus, since Vehicle2 and Vehicle3 use the same prefix
for Subnet1 and they are within the wireless communication range, for Subnet1 and they are within the wireless communication range,
they can communicate directly with each other. Note that in a multi- they can communicate directly with each other. Note that in a multi-
link subnet, a vehicle (e.g., Vehicle1 and Vehicle2 in Figure 1) can link subnet, a vehicle (e.g., Vehicle2 and Vehicle3 in Figure 1) can
configure its global IPv6 address through an address registration configure its global IPv6 address through an address registration
procedure including a multihop Duplicate Address Detection (DAD), procedure including a multihop DAD, which is specified in VND
which is specified in Vehicular Neighbor Discovery (VND)
[I-D.IPWAVE-VND]. [I-D.IPWAVE-VND].
On the other hand, Subnet2 uses a prefix different from Subnet1's. On the other hand, Subnet2 uses a prefix different from Subnet1's.
Vehicle4 residing in Subnet2 cannot talk to Vehicle3 directly because Vehicle4 residing in Subnet2 cannot talk to Vehicle3 directly because
they belong to different subnets. Vehicles can construct a connected they belong to different subnets. Vehicles can construct a connected
VANET, so they can communicate with each other without the relaying VANET, so they can communicate with each other without the relaying
of an RSU, but the forwarding over the VANET. In the case where two of an RSU, but the forwarding over the VANET. In the case where two
vehicles belong to the same multi-link subnet, but they are not vehicles belong to the same multi-link subnet, but they are not
connected in the same VANET, they can use RSUs. In Figure 1, even connected in the same VANET, they can use RSUs. In Figure 1, even
though Vehicle2 are disconnected from Vehicle3, they can communicate though Vehicle1 are disconnected from Vehicle3, they can communicate
indirectly with each other through RSUs such as RSU1 and RSU2. indirectly with each other through RSUs such as RSU1 and RSU2.
In Figure 1, it is assumed that Vehicle2 communicates with the In Figure 1, it is assumed that Vehicle2 communicates with the
corresponding node denoted as CN1 where Vehicle2 is moving in the corresponding node denoted as CN1 where Vehicle2 is moving in the
wireless coverage of RSU1. When Vehicle2 moves out of the coverage wireless coverage of RSU1. When Vehicle2 moves out of the coverage
of RSU1 and moves into the coverage of RSU2 where RSU1 and RSU2 of RSU1 and moves into the coverage of RSU2 where RSU1 and RSU2 share
shares the same prefix, the packets sent by CN1 should be routed the same prefix, the packets sent by CN1 should be routed toward
toward Vehicle2. Also, when Vehicle2 moves out of the coverage of Vehicle2. Also, when Vehicle2 moves out of the coverage of RSU2 and
RSU2 and moves into the coverage of RSU3 where RSU2 and RSU3 use two moves into the coverage of RSU3 where RSU2 and RSU3 use two different
different prefixes, the packets of CN1 should be delivered to prefixes, the packets of CN1 should be delivered to Vehicle2. With a
Vehicle2. With a handoff procedure, a sender's packets can be handoff procedure, a sender's packets can be delivered to a
delivered to a destination vehicle which the destination vehicle is destination vehicle which is moving in the wireless coverage areas.
moving in the wireless coverage areas. Thus, this document specifies Thus, this document specifies a mobility management scheme in the
a mobility management scheme in the vehicular network architecture, vehicular network architecture, as shown in Figure 1.
as shown in Figure 1.
5. Mobility Management 5. Mobility Management
This section explains the detailed procedure of mobility management This section explains the detailed procedure of mobility management
of a vehicle in a vehicular network as shown in Figure 1. of a vehicle in a vehicular network as shown in Figure 1.
5.1. Network Attachment of a Vehicle 5.1. Network Attachment of a Vehicle
A mobility management is required for the seamless communication of A mobility management is required for the seamless communication of
vehicles moving between the RSUs. When a vehicle moves into the vehicles moving between the RSUs. When a vehicle moves into the
coverage of another RSU, a different IP address is assigned to the coverage of another RSU, a different IP address is assigned to the
vehicle, resulting in the reconfiguration of transport-layer session vehicle, resulting in the re-configuration of transport-layer session
information (i.e., an end-point's IP address) to avoid service information (i.e., an end-point's IP address) to avoid service
disruption. Considering this issue, this document proposes a handoff disruption. Considering this issue, this document proposes a handoff
mechanism for seamless communication. 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 for 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.
Vehicle RSU Mobility Anchor Vehicle RSU MA
| | | | | |
|-RS with Mobility Info->| | |-RS with Mobility Info->| |
| [VMI] | | | [VMI] | |
| | | | | |
| |--------PBU------>| | |--------PBU------>|
| | | | | |
| | | | | |
| |<-------PBA-------| | |<-------PBA-------|
| | | | | |
| | | | | |
skipping to change at page 7, line 47 skipping to change at page 7, line 47
the MA. After this binding update, the RSU sends back an RA message the MA. After this binding update, the RSU sends back an RA message
to the vehicle, which includes the RSU's prefix for the address to the vehicle, which includes the RSU's prefix for the address
autoconfiguration of the vehicle. autoconfiguration of the vehicle.
When the vehicle receives the RA message, it performs the address When the vehicle receives the RA message, it performs the address
registration procedure including a multihop DAD for its global IP registration procedure including a multihop DAD for its global IP
address based on the prefix announced by the RA message according to address based on the prefix announced by the RA message according to
the VND [I-D.IPWAVE-VND]. the VND [I-D.IPWAVE-VND].
In PMIPv6, a unique prefix is allocated to each vehicle by an MA In PMIPv6, a unique prefix is allocated to each vehicle by an MA
(i.e., LMA), but in this document, a unique IP address is allocated (i.e., LMA) to guarantee the uniqueness of each address, but in this
to each vehicle by an MA through the multihop-DAD-based address document, a unique IP address is allocated to each vehicle with the
registration. This unique IP address allocation can reduce the waste same prefix by an MA in its domain through the multihop-DAD-based
of IP prefixes by the legacy PMIPv6 because vehicles in a multi-link address registration. This unique IP address allocation ensures that
is allocated with a unique IP address based on the same prefix. vehicles own unique IP addresses in a multi-link subnet and can
reduce the waste of IP prefixes in legacy PMIPv6.
5.2. Handoff within One Prefix Domain 5.2. Handoff within One Prefix Domain
When the vehicle changes its location and its current RSU (denoted as When the vehicle changes its location and its current RSU (denoted as
c-RSU) detects that the vehicles moves out of its coverage, c-RSU c-RSU) detects that the vehicle is moving out of its coverage, c-RSU
needs to report the movement of the vehicle into the coverage of needs to report the leaving of the vehicle to the MA and de-register
another RSU to the MA. the binding via PBU.
Vehicle c-RSU Mobility Anchor n-RSU Vehicle c-RSU MA n-RSU
| | | | | | | |
| |===Bi-Dir Tunnel==| | | |===Bi-Dir Tunnel==| |
| | | | | | | |
| | | | | | | |
| |----DeReg PBU---->| | | |----DeReg PBU---->| |
| | | | | | | |
| | | | | | | |
| |<-------PBA-------| | | |<-------PBA-------| |
| | | | | | | |
| | | | | | | |
skipping to change at page 8, line 42 skipping to change at page 8, line 44
| | | | | |
| | | | | |
| |===Bi-Dir Tunnel==| | |===Bi-Dir Tunnel==|
| | | | | |
| | | | | |
|<--------------------RA with prefix---------------------| |<--------------------RA with prefix---------------------|
| | | |
Figure 3: Handoff of a Vehicle within One Prefix Domain with PMIPv6 Figure 3: Handoff of a Vehicle within One Prefix Domain with PMIPv6
With this report, the MA can change the end-point of the tunnel for With this report, the MA can figure out the new RSU (denoted as
the vehicle into the new RSU's IP address. n-RSU) based on the vehicle's trajectory and change the end-point of
the tunnel into n-RSU's IP address for the vehicle or get ready to
detect new binding requests.
Figure 3 shows the handoff of a vehicle within one prefix domain Figure 3 shows the handoff of a vehicle within one prefix domain
(i.e., a multi-link subnet) with PMIPv6. As shown in the figure, (i.e., a multi-link subnet) with PMIPv6. As shown in the figure,
when the MA receives a new PBU from the new RSU, it changes the when the MA receives a new PBU from the n-RSU, it changes the
tunnel's end-point from the current RSU (c-RSU) to the new RSU tunnel's end-point from the c-RSU to n-RSU. If there are ongoing IP
(n-RSU). If there is ongoing IP packets toward the vehicle, the MA packets toward the vehicle, the MA encapsulates the packets and then
encapsulates the packets and then forwards them towards n-RSU. forwards them towards n-RSU. Through this network-based mobility
Through this network-based mobility management, the vehicle is not management, the vehicle is not aware of any changes at its network
aware of any changes at its network layer and can maintain its layer and can maintain its transport-layer sessions without any
transport-layer sessions without any disruption. disruption.
Vehicle c-RSU n-RSU Vehicle c-RSU n-RSU
| | | | | |
|---------------------| | |---------------------| |
|c-RSU detects leaving| | |c-RSU detects leaving| |
|---------------------| | |---------------------| |
| |--------PBU------>| | |--------PBU------>|
| | | | | |
| |===Bi-Dir Tunnel==| | |===Bi-Dir Tunnel==|
| | | | | |
skipping to change at page 9, line 29 skipping to change at page 9, line 34
|(--------RS with Mobility Info-------->)| |(--------RS with Mobility Info-------->)|
| [VMI] | | [VMI] |
| | | |
|<------------RA with prefix-------------| |<------------RA with prefix-------------|
| | | |
Figure 4: Handoff of a Vehicle within One Prefix Domain with DMM Figure 4: Handoff of a Vehicle within One Prefix Domain with DMM
If c-RSU and n-RSU are adjacent, that is, vehicles are moving in If c-RSU and n-RSU are adjacent, that is, vehicles are moving in
specified routes with fixed RSU allocation, the procedure can be specified routes with fixed RSU allocation, the procedure can be
simplified by constructing bidirectional tunnel directly between them simplified by constructing the bidirectional tunnel directly between
(cancel the intervention of MA) to alleviate the traffic flow in MA them (cancel the intervention of MA) to alleviate the traffic flow in
as well as reduce handoff delay. MA as well as reduce handoff delay.
Figure 4 shows the handoff of a vehicle within one prefix domain (as Figure 4 shows the handoff of a vehicle within one prefix domain (as
a multi-link subnet) with DMM [I-D.DMM-PMIPv6]. RSUs are in charge a multi-link subnet) with DMM [I-D.DMM-PMIPv6]. RSUs are in charge
of detecting when a node joins or moves through its domain. If c-RSU of detecting when a node joins or moves through its domain. If c-RSU
detects that the vehicle is going to leave its coverage and to enter detects that the vehicle is going to leave its coverage and to enter
the area of an adjacent RSU, it sends a PBU message to inform n-RSU the area of an adjacent RSU, it sends a PBU message to inform n-RSU
of the handoff of vehicle. If n-RSU receives the PBU message, it of the handoff of the vehicle. If n-RSU receives the PBU message, it
constructs a bidirectional tunnel between c-RSU and itself, and then constructs a bidirectional tunnel between c-RSU and itself, and then
sends back a PBA message as an acknowledgment to c-RSU. If there are sends back a PBA message as an acknowledgment to c-RSU. If there are
ongoing IP packets toward the vehicle, c-RSU encapsulates the packets ongoing IP packets toward the vehicle, c-RSU encapsulates the packets
and then forwards them to n-RSU. When n-RSU detects the entrance of and then forwards them to n-RSU. When n-RSU detects the entrance of
the vehicle, it directly sends an RA message to the vehicle so that the vehicle, it directly sends an RA message to the vehicle so that
the vehicle can assure that it is still connected to a router for its the vehicle can assure that it is still connected to a router with
current prefix. If the vehicle sends an RS message to n-RSU, n-RSU its current prefix. If the vehicle sends an RS message to n-RSU,
responds to the RA message by sending an RA to the vehicle. n-RSU responds to the RS message by sending an RA to the vehicle.
5.3. Handoff between Multiple Prefix Domains 5.3. Handoff between Multiple Prefix Domains
When the vehicle moves from a prefix domain to another prefix domain, When the vehicle moves from a prefix domain to another prefix domain,
a handoff between multiple prefix domains is required. As shown in a handoff between multiple prefix domains is required. As shown in
Figure 1, when Vehicle3 moves from the subnet of RSU2 (i.e., Subnet1) Figure 1, when Vehicle3 moves from the subnet of RSU2 (i.e., Subnet1)
to the subnet of RSU3 (i.e., Subnet2), a multiple domain handoff is to the subnet of RSU3 (i.e., Subnet2), a multiple domain handoff is
performed through the cooperation of RSU2, RSU3, MA1 and MA2. performed through the cooperation of RSU2, RSU3, MA1 and MA2.
Vehicle c-RSU MA1 MA2 n-RSU Vehicle c-RSU MA1 MA2 n-RSU
| | | | | | | | | |
| |==Bi-Dir Tunnel==| | | | |==Bi-Dir Tunnel==| | |
| | | | | | | | | |
| | | | | | | | | |
| |---DeReg PBU---->| | | | |---DeReg PBU---->| | |
| | |-------PBU----->| | | | |-------PBU----->| |
| | | | | | | | | |
| |<------PBA-------| |-------PBA------>| | |<------PBA-------| |-------PBA------>|
| | | | | | | | | |
| | | |==Bi-Dir Tunnel==| | | | |==Bi-Dir Tunnel==|
| | | | | | | | | |
| | | | | | | | | |
|(----------------------RS with Mobility Info------------------->)| |(----------------------RS with Mobility Info------------------->)|
| | |[VMI] | | | | |[VMI] | |
| | | | | | | | | |
| | | | | | | | | |
|<----------------------RA with prefix1 (c-RSU)-------------------| |<----------------------RA with prefix1 (c-RSU)-------------------|
| | | | | | | | | |
|<----------------------RA with prefix2 (n-RSU)-------------------| |<----------------------RA with prefix2 (n-RSU)-------------------|
| | | | | | | | | |
Figure 5: Handoff of a Vehicle between Multiple Prefix Domains with Figure 5: Handoff of a Vehicle between Multiple Prefix Domains with
PMIPv6 PMIPv6
Figure 5 shows the handoff of a vehicle between two prefix domains Figure 5 shows the handoff of a vehicle between two prefix domains
(i.e., two multi-link subnets) with PMIPv6. When the vehicle moves (i.e., two multi-link subnets) with PMIPv6. When the vehicle moves
out of its current RSU (denoted as c-RSU) belonging to Subnet1, and out of its c-RSU belonging to Subnet1, and moves into the n-RSU
moves into the next RSU (n-RSU) belonging to Subnet2, c-RSU detects belonging to Subnet2, c-RSU detects the vehicle's leaving and reports
that the vehicles moves out of its coverage. c-RSU reports the to MA1. MA1 figures out that the vehicle will get into the coverage
movement of the vehicle into the coverage of another RSU (n-RSU) to of the n-RSU based on its trajectory and sends MA2 a PBU message to
MA1. MA1 sends MA2 a PBU message to inform MA2 that the vehicle will inform MA2 that the vehicle will enter the coverage of n-RSU
enter the coverage of n-RSU belonging to MA2. MA2 send n-RSU a PBA belonging to MA2. MA2 sends n-RSU a PBA message to inform n-RSU that
message to inform n-RSU that the vehicle will enter the coverage of the vehicle will enter the coverage of n-RSU along with handoff
n-RSU along with handoff context such as c-RSU's context information context such as c-RSU's context information (e.g., c-RSU's link-local
(e.g., c-RSU's link-local address and prefix called prefix1), and the address and prefix called prefix1), and the vehicle's context
vehicle's context information (e.g., the vehicle's global IP address information (e.g., the vehicle's global IP address and MAC address).
and MAC address). After n-RSU receives the PBA message including the After n-RSU receives the PBA message including the handoff context
handoff context from MA2, it sets up a bi-directional tunnel with from MA2, it sets up a bi-directional tunnel with MA2, and generates
MA2, and generates RA messages with c-RSU's context information. RA messages with c-RSU's context information. That is, n-RSU
pretends to be a router belonging to Subnet1. When the vehicle
That is, n-RSU pretents to be a router belonging to Subnet1. When receives RA from n-RSU, it can maintain its connection with its
the vehicle receives the RA from n-RSU, it can maintain its corresponding node (i.e., CN1). Note that n-RSU also sends RA
connection with its corresponding node (i.e., CN1). Note that n-RSU messages with its domain prefix called prefix2. The vehicle
also sends RA messages with its domain prefix called prefix2. The configures another global IP address with prefix2, and can use it for
vehicle configures another global IP address with prefix2, and can communication with neighboring vehicles under the coverage of n-RSU.
use it for the communication with neighboring vehicles under the
coverage of n-RSU.
If c-RSU and n-RSU are adjacent, that is, vehicles are moving in If c-RSU and n-RSU are adjacent, that is, vehicles are moving in
specified routes with fixed RSU allocation, the procedure can be specified routes with fixed RSU allocation, the procedure can be
simplified by constructing bidirectional tunnel directly between them simplified by constructing the bidirectional tunnel directly between
(cancel the intervention of MA) to alleviate the traffic flow in MA them (cancel the intervention of MAs) to alleviate the traffic flow
as well as reduce handoff delay. in MA as well as reduce handoff delay.
Vehicle c-RSU n-RSU Vehicle c-RSU n-RSU
| | | | | |
|---------------------| | |---------------------| |
|c-RSU detects leaving| | |c-RSU detects leaving| |
|---------------------| | |---------------------| |
| |--------PBU------>| | |--------PBU------>|
| | | | | |
| |===Bi-Dir Tunnel==| | |===Bi-Dir Tunnel==|
| | | | | |
skipping to change at page 12, line 5 skipping to change at page 12, line 4
that the vehicle is going to leave its coverage and to enter the area that the vehicle is going to leave its coverage and to enter the area
of an adjacent RSU (n-RSU) belonging to a different prefix domain, it of an adjacent RSU (n-RSU) belonging to a different prefix domain, it
sends a PBU message to inform n-RSU that the vehicle will enter the sends a PBU message to inform n-RSU that the vehicle will enter the
coverage of n-RSU along with handoff context such as c-RSU's context coverage of n-RSU along with handoff context such as c-RSU's context
information (e.g., c-RSU's link-local address and prefix called information (e.g., c-RSU's link-local address and prefix called
prefix1), and the vehicle's context information (e.g., the vehicle's prefix1), and the vehicle's context information (e.g., the vehicle's
global IP address and MAC address). After n-RSU receives the PBA global IP address and MAC address). After n-RSU receives the PBA
message including the handoff context from c-RSU, it sets up a bi- message including the handoff context from c-RSU, it sets up a bi-
directional tunnel with c-RSU, and generates RA messages with c-RSU's directional tunnel with c-RSU, and generates RA messages with c-RSU's
context information. That is, n-RSU pretends to be a router context information. That is, n-RSU pretends to be a router
belonging to Subnet1. When the vehicle receives the RA from n-RSU, belonging to Subnet1. When the vehicle receives RA from n-RSU, it
it can maintain its connection with its corresponding node (i.e., can maintain its connection with its corresponding node (i.e., CN1).
CN1). Note that n-RSU also sends RA messages with its domain prefix Note that n-RSU also sends RA messages with its domain prefix called
called prefix2. The vehicle configures another global IP address prefix2. The vehicle configures another global IP address with
with prefix2, and can use it for the communication with neighboring prefix2, and can use it for communication with neighboring vehicles
vehicles under the coverage of n-RSU. under the coverage of n-RSU.
6. Security Considerations 6. Security Considerations
This document shares all the security issues of Vehicular ND This document shares all the security issues of Vehicular ND
[I-D.IPWAVE-VND], Proxy MIPv6 [RFC5213], and DMM [I-D.IPWAVE-VND], Proxy MIPv6 [RFC5213], and DMM
[RFC7333][RFC7429][I-D.DMM-PMIPv6]. [RFC7333][RFC7429][I-D.DMM-PMIPv6].
7. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at page 13, line 14 skipping to change at page 13, line 8
[I-D.DMM-PMIPv6] [I-D.DMM-PMIPv6]
Bernardos, CJ., Oliva, A., Giust, F., Zuniga, JC., and A. Bernardos, CJ., Oliva, A., Giust, F., Zuniga, JC., and A.
Mourad, "Proxy Mobile IPv6 extensions for Distributed Mourad, "Proxy Mobile IPv6 extensions for Distributed
Mobility Management", draft-ietf-dmm-pmipv6-dlif-04 (work Mobility Management", draft-ietf-dmm-pmipv6-dlif-04 (work
in progress), January 2019. in progress), January 2019.
[I-D.IPWAVE-PS] [I-D.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-08 (work in draft-ietf-ipwave-vehicular-networking-09 (work in
progress), March 2019. progress), May 2019.
[I-D.IPWAVE-VND] [I-D.IPWAVE-VND]
Jeong, J., Ed., Shen, Y., and Z. Xiang, "IPv6 Neighbor Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular
Discovery for IP-Based Vehicular Networks", draft-jeong- Neighbor Discovery for IP-Based Vehicular Networks",
ipwave-vehicular-neighbor-discovery-06 (work in progress), draft-jeong-ipwave-vehicular-neighbor-discovery-07 (work
March 2019. in progress), July 2019.
[IEEE-802.11-OCB] [IEEE-802.11-OCB]
"Part 11: Wireless LAN Medium Access Control (MAC) and "Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", IEEE Std Physical Layer (PHY) Specifications", IEEE Std
802.11-2016, December 2016. 802.11-2016, December 2016.
[TS-23.285-3GPP] [TS-23.285-3GPP]
3GPP, "Architecture Enhancements for V2X Services", 3GPP 3GPP, "Architecture Enhancements for V2X Services", 3GPP
TS 23.285, June 2018. TS 23.285, June 2018.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
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
Networks", IEEE Transactions on Intelligent Transportation Networks", IEEE Transactions on Intelligent Transportation
Systems, vol. 14, no. 1, March 2013. Systems, vol. 14, no. 1, March 2013.
[WAVE-1609.0] [WAVE-1609.0]
IEEE 1609 Working Group, "IEEE Guide for Wireless Access IEEE 1609 Working Group, "IEEE Guide for Wireless Access
in Vehicular Environments (WAVE) - Architecture", IEEE Std in Vehicular Environments (WAVE) - Architecture", IEEE Std
1609.0-2013, March 2014. 1609.0-2013, March 2014.
Appendix A. Acknowledgments Appendix A. Changes from draft-jeong-ipwave-vehicular-mobility-
management-00
The following changes are made from draft-jeong-ipwave-vehicular-
mobility-management-00:
o In Section 4.1, the description of the vehicular network
architecture is clarified.
o In Section 5.2, the description on the handoff procedure within
one prefix domain is clarified.
o In Section 5.3, the decription on the the handoff procedure within
multiple prefix domains is clarified.
o Some typo errors are corrected and the repeated acronyms are
removed.
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 by the MSIT (Ministry of Science and ICT),
Korea, under the ITRC (Information Technology Research Center)
support program (IITP-2019-2017-0-01633) supervised by the IITP
(Institute for Information & communications Technology Promotion).
Authors' Addresses Authors' Addresses
Jaehoon Paul Jeong Jaehoon Paul Jeong
Department of Software Department of Computer Science and Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4957 Phone: +82 31 299 4957
Fax: +82 31 290 7996 Fax: +82 31 290 7996
EMail: pauljeong@skku.edu EMail: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Yiwen Chris Shen Yiwen Chris Shen
Department of Electrical and Computer Engineering Department of Electrical and Computer Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4106 Phone: +82 31 299 4106
Fax: +82 31 290 7996 Fax: +82 31 290 7996
EMail: chrisshen@skku.edu EMail: chrisshen@skku.edu
 End of changes. 36 change blocks. 
141 lines changed or deleted 161 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/