[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

IPWAVE Working Group                                            J. Jeong
Internet-Draft                                                   Y. Shen
Intended status: Standards Track                                Z. Xiang
Expires: September 29, 2019                      Sungkyunkwan University
                                                          March 28, 2019


     Vehicular Mobility Management for IP-Based Vehicular Networks
          draft-jeong-ipwave-vehicular-mobility-management-00

Abstract

   This document specifies a vehicular mobility management scheme for
   IP-based vehicular networks.  The vehicular mobility management
   scheme takes advantage of a vehicular link model based on a multi-
   link subnet.  With a vehicle's mobility information (e.g., position,
   speed, and direction) and navigation path (i.e., trajectory), it can
   provide a moving vehicle with proactive and seamless handoff along
   with its trajectory.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 29, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Jeong, et al.          Expires September 29, 2019               [Page 1]


Internet-Draft        Vehicular Mobility Management           March 2019


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Vehicular Network Architecture  . . . . . . . . . . . . . . .   4
     4.1.  Vehicular Network . . . . . . . . . . . . . . . . . . . .   4
   5.  Mobility Management . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Network Attachment of a Vehicle . . . . . . . . . . . . .   6
     5.2.  Handoff within One Prefix Domain  . . . . . . . . . . . .   8
     5.3.  Handoff between Multiple Prefix Domains . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   This document proposes a mobility management scheme for IP-based
   vehicular networks, which is called vehicular mobility management
   (VMM).  This vehicular mobility management is tailored for a
   vehicular network architecture and a vehicular link model described
   in IPWAVE problem statement document [I-D.IPWAVE-PS].

   To support the interaction between vehicles or between vehicles and
   Rode-Side Units (RSUs), Vehicular Neighbor Discovery (VND) is
   proposed as an enhanced IPv6 Neighbor Discovery (ND) for IP-based
   vehicular networks [I-D.IPWAVE-VND].  For an efficient IPv6 Stateless
   Address Autoconfiguration (SLAAC) [RFC4862], VND adopts an optimized
   Address Registration using a multihop Duplicate Address Detection
   (DAD).  This multihop DAD enables a vehicle to have a unique IP
   address in a multi-link subnet that consists of multiple wireless
   subnets with the same IP prefix, which corresponds to wireless
   coverage of multiple Road-Side Units (RSUs).  Also, VND supports IP
   packet routing via a connected Vehicular Ad Hoc Network (VANET) by
   letting vehicles exchange the prefixes of their internal networks
   through their external wireless interface.

   The mobility management in this multi-link subnet needs a new
   approach from the legacy mobility management schemes.  This document
   aims at an efficient mobility management scheme called vehicular
   mobility management called VMM to support efficient V2V, V2I, and V2X



Jeong, et al.          Expires September 29, 2019               [Page 2]


Internet-Draft        Vehicular Mobility Management           March 2019


   communications in a road network.  The VMM takes advantage of the
   mobility information (e.g., a vehicle's speed, direction, and
   position) and trajectory (i.e., navigation path) of each vehicle
   registered into a Traffic Control Center (TCC) in the vehicular
   cloud.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Terminology

   This document uses the terminology described in [RFC4861] and
   [RFC4862].  In addition, the following new terms are defined as
   below:

   o  DMM: Acronym for "Distributed Mobility Management"
      [RFC7333][RFC7429].

   o  Mobility Anchor (MA): A node that maintains IP addresses and
      mobility information of vehicles in a road network to support
      their address autoconfiguration and mobility management with a
      binding table.  It has end-to-end connections with RSUs under its
      control.

   o  On-Board Unit (OBU): A node that has a network interface (e.g.,
      IEEE 802.11-OCB and Cellular V2X (C-V2X) [TS-23.285-3GPP]) for
      wireless communications with other OBUs and RSUs, and may be
      connected to in-vehicle devices or networks.  An OBU is mounted on
      a vehicle.  It is assumed that a radio navigation receiver (e.g.,
      Global Positioning System (GPS)) is included in a vehicle with an
      OBU for efficient navigation.

   o  OCB: Acronym for "Outside the Context of a Basic Service Set"
      [IEEE-802.11-OCB].

   o  Road-Side Unit (RSU): A node that has physical communication
      devices (e.g., IEEE 802.11-OCB and C-V2X) for wireless
      communications with vehicles and is also connected to the Internet
      as a router or switch for packet forwarding.  An RSU is typically
      deployed on the road infrastructure, either at an intersection or
      in a road segment, but may also be located in car parking areas.

   o  Traffic Control Center (TCC): A node that maintains road
      infrastructure information (e.g., RSUs, traffic signals, and loop
      detectors), vehicular traffic statistics (e.g., average vehicle



Jeong, et al.          Expires September 29, 2019               [Page 3]


Internet-Draft        Vehicular Mobility Management           March 2019


      speed and vehicle inter-arrival time per road segment), and
      vehicle information (e.g., a vehicle's identifier, position,
      direction, speed, and trajectory as a navigation path).  TCC is
      included in a vehicular cloud for vehicular networks.

   o  Vehicular Cloud: A cloud infrastructure for vehicular networks,
      having compute nodes, storage nodes, and network nodes.

   o  WAVE: Acronym for "Wireless Access in Vehicular Environments"
      [WAVE-1609.0].

4.  Vehicular Network Architecture

   This section describes a vehicular network architecture for V2V and
   V2I communication.  A vehicle and an RSU have their internal networks
   including in-vehicle devices or servers, respectively.

4.1.  Vehicular Network

   A vehicular network architecture for V2I and V2V is illustrated in
   Figure 1.  In this figure, there is a vehicular cloud having a
   Traffic Control Center (TCC).  The TCC has Mobility Anchors (MAs) for
   the mobility management of vehicles under its control.  Each MA is in
   charge of the mobility management of vehicles under its prefix
   domain, which is a multi-link subnet of RSUs sharing the same prefix
   [I-D.IPWAVE-PS].  A vehicular network is a wireless network
   consisting of RSUs and vehicles.  RSUs are interconnected with each
   other through a wired network, and vehicles can construct Vehicular
   Ad Hoc Networks (VANET).






















Jeong, et al.          Expires September 29, 2019               [Page 4]


Internet-Draft        Vehicular Mobility Management           March 2019


                      *-----------------------------------------*
                     *          TCC in Vehicular Cloud           *
                    *   +-------------------------------------+   *
  +--------+       *    |   +---------+         +---------+   |    *
  |  CN1   |<---->*     |   |   MA1   |<------->|   MA2   |   |     *
  +--------+      *     |   +---------+         +---------+   |     *
                   *    +-------------------------------------+    *
                    *           ^                    ^            *
                     *          |      INTERNET      |           *
                      *---------v--------------------v----------*
                       ^               ^                     ^
                       | Ethernet      |                     |
                       |               |                     |
                       v               v                     v
                  +--------+ Ethernet +--------+ Ethernet +--------+
                  |  RSU1  |<-------->|  RSU2  |<-------->|  RSU3  |
                  +--------+          +--------+          +--------+
                     ^                   ^                   ^
                     :                   :                   :
              +-----------------------------------+  +-----------------+
              |      : V2I           V2I :        |  |   V2I :         |
              |      v                   v        |  |       v         |
 +--------+   |   +--------+       +--------+     |  |  +--------+     |
 |Vehicle1|======>|Vehicle2|======>|Vehicle3|====>|  |  |Vehicle4|====>|
 |        |<.....>|        |<.....>|        |     |  |  |        |     |
 +--------+  V2V  +--------+  V2V  +--------+     |  |  +--------+     |
              |                                   |  |                 |
              +-----------------------------------+  +-----------------+
                             Subnet1                       Subnet2

       <----> Wired Link   <....> Wireless Link   ===> Moving Direction

   Figure 1: A Vehicular Network Architecture for V2I and V2V Networking

   In Figure 1, three RSUs are deployed either at intersections or along
   roadways.  They are connected to an MA through wired networks.  In
   the vehicular network, there are two subnets such as Subnet1 and
   Subnet2.  Subnet1 is a multi-link subnet consisting of multiple
   wireless coverage areas of multiple RSUs, and those areas share the
   same IPv6 prefix to construct a single logical subnet
   [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
   for Subnet1 and they are within the wireless communication range,
   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
   configure its global IPv6 address through an address registration
   procedure including a multihop Duplicate Address Detection (DAD),




Jeong, et al.          Expires September 29, 2019               [Page 5]


Internet-Draft        Vehicular Mobility Management           March 2019


   which is specified in Vehicular Neighbor Discovery (VND)
   [I-D.IPWAVE-VND].

   On the other hand, Subnet2 uses a prefix different from Subnet1's.
   Vehicle4 residing in Subnet2 cannot talk to Vehicle3 directly because
   they belong to different subnets.  Vehicles can construct a connected
   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
   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
   though Vehicle2 are disconnected from Vehicle3, they can communicate
   indirectly with each other through RSUs such as RSU1 and RSU2.

   In Figure 1, it is assumed that Vehicle2 communicates with the
   corresponding node denoted as CN1 where Vehicle2 is moving in the
   wireless coverage of RSU1.  When Vehicle2 moves out of the coverage
   of RSU1 and moves into the coverage of RSU2 where RSU1 and RSU2
   shares the same prefix, the packets sent by CN1 should be routed
   toward Vehicle2.  Also, when Vehicle2 moves out of the coverage of
   RSU2 and moves into the coverage of RSU3 where RSU2 and RSU3 use two
   different prefixes, the packets of CN1 should be delivered to
   Vehicle2.  With a handoff procedure, a sender's packets can be
   delivered to a destination vehicle which the destination vehicle is
   moving in the wireless coverage areas.  Thus, this document specifies
   a mobility management scheme in the vehicular network architecture,
   as shown in Figure 1.

5.  Mobility Management

   This section explains the detailed procedure of mobility management
   of a vehicle in a vehicular network as shown in Figure 1.

5.1.  Network Attachment of a Vehicle

   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., an end-point's IP address) to avoid service
   disruption.  Considering this issue, this document proposes a handoff
   mechanism for seamless communication.

   In [VIP-WAVE], the authors constructed a network-based mobility
   management scheme using Proxy Mobile IPv6 (PMIPv6) [RFC5213], which
   is highly suitable to vehicular networks.  This document uses a
   mobility management procedure similar to PMIPv6 along with prefix
   discovery.




Jeong, et al.          Expires September 29, 2019               [Page 6]


Internet-Draft        Vehicular Mobility Management           March 2019


             Vehicle                    RSU          Mobility Anchor
                |                        |                  |
                |-RS with Mobility Info->|                  |
                |         [VMI]          |                  |
                |                        |                  |
                |                        |--------PBU------>|
                |                        |                  |
                |                        |                  |
                |                        |<-------PBA-------|
                |                        |                  |
                |                        |                  |
                |                        |===Bi-Dir Tunnel==|
                |                        |                  |
                |                        |                  |
                |<----RA with prefix-----|                  |
                |                        |                  |


     Figure 2: Message Interaction for a Vehicle's Network Attachment

   Figure 2 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 an RS message 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 2) 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, which includes the RSU's prefix for the address
   autoconfiguration of the vehicle.

   When the vehicle receives the RA message, it performs the address
   registration procedure including a multihop DAD for its global IP
   address based on the prefix announced by the RA message according to
   the VND [I-D.IPWAVE-VND].

   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
   to each vehicle by an MA through the multihop-DAD-based address
   registration.  This unique IP address allocation can reduce the waste
   of IP prefixes by the legacy PMIPv6 because vehicles in a multi-link
   is allocated with a unique IP address based on the same prefix.



Jeong, et al.          Expires September 29, 2019               [Page 7]


Internet-Draft        Vehicular Mobility Management           March 2019


5.2.  Handoff within One Prefix Domain

   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
   needs to report the movement of the vehicle into the coverage of
   another RSU to the MA.

      Vehicle            c-RSU          Mobility Anchor        n-RSU
         |                  |                  |                  |
         |                  |===Bi-Dir Tunnel==|                  |
         |                  |                  |                  |
         |                  |                  |                  |
         |                  |----DeReg PBU---->|                  |
         |                  |                  |                  |
         |                  |                  |                  |
         |                  |<-------PBA-------|                  |
         |                  |                  |                  |
         |                  |                  |                  |
         |                  |                  |                  |
         |                  |                  |                  |
         |                  |                  |                  |
         |(------------------RS with Mobility Info-------------->)|
         |                          [VMI]      |                  |
         |                                     |<-------PBU-------|
         |                                     |                  |
         |                                     |                  |
         |                                     |--------PBA------>|
         |                                     |                  |
         |                                     |                  |
         |                                     |===Bi-Dir Tunnel==|
         |                                     |                  |
         |                                     |                  |
         |<--------------------RA with prefix---------------------|
         |                                                        |


    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
   the vehicle into the new RSU's IP address.

   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,
   when the MA receives a new PBU from the new 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 vehicle, the MA
   encapsulates the packets and then forwards them towards n-RSU.
   Through this network-based mobility management, the vehicle is not



Jeong, et al.          Expires September 29, 2019               [Page 8]


Internet-Draft        Vehicular Mobility Management           March 2019


   aware of any changes at its network layer and can maintain its
   transport-layer sessions without any disruption.

           Vehicle               c-RSU              n-RSU
              |                     |                  |
              |---------------------|                  |
              |c-RSU detects leaving|                  |
              |---------------------|                  |
              |                     |--------PBU------>|
              |                     |                  |
              |                     |===Bi-Dir Tunnel==|
              |                     |                  |
              |                     |<-------PBA-------|
              |                     |                  |
              |                     |                  |
              |(--------RS with Mobility Info-------->)|
              |                 [VMI]                  |
              |                                        |
              |<------------RA with prefix-------------|
              |                                        |

     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
   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 handoff delay.

   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
   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
   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
   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
   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
   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
   current prefix.  If the vehicle sends an RS message to n-RSU, n-RSU
   responds to the RA message by sending an RA to the vehicle.








Jeong, et al.          Expires September 29, 2019               [Page 9]


Internet-Draft        Vehicular Mobility Management           March 2019


5.3.  Handoff between Multiple Prefix Domains

   When the vehicle moves from a prefix domain to another prefix domain,
   a handoff between multiple prefix domains is required.  As shown in
   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
   performed through the cooperation of RSU2, RSU3, MA1 and MA2.

 Vehicle      c-RSU               MA1              MA2             n-RSU
   |            |                 |                |                 |
   |            |==Bi-Dir Tunnel==|                |                 |
   |            |                 |                |                 |
   |            |                 |                |                 |
   |            |---DeReg PBU---->|                |                 |
   |            |                 |-------PBU----->|                 |
   |            |                 |                |                 |
   |            |<------PBA-------|                |-------PBA------>|
   |            |                 |                |                 |
   |            |                 |                |==Bi-Dir Tunnel==|
   |            |                 |                |                 |
   |            |                 |                |                 |
   |(----------------------RS with Mobility Info------------------->)|
   |            |                 |[VMI]           |                 |
   |            |                 |                |                 |
   |            |                 |                |                 |
   |<----------------------RA with prefix1 (c-RSU)-------------------|
   |            |                 |                |                 |
   |<----------------------RA with prefix2 (n-RSU)-------------------|
   |            |                 |                |                 |

    Figure 5: Handoff of a Vehicle between Multiple Prefix Domains with
                                  PMIPv6

   Figure 5 shows the handoff of a vehicle between two prefix domains
   (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
   moves into the next RSU (n-RSU) belonging to Subnet2, c-RSU detects
   that the vehicles moves out of its coverage. c-RSU reports the
   movement of the vehicle into the coverage of another RSU (n-RSU) to
   MA1.  MA1 sends MA2 a PBU message to inform MA2 that the vehicle will
   enter the coverage of n-RSU belonging to MA2.  MA2 send n-RSU a PBA
   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 information
   (e.g., c-RSU's link-local address and prefix called prefix1), and the
   vehicle's context information (e.g., the vehicle's global IP address
   and MAC address).  After n-RSU receives the PBA message including the
   handoff context from MA2, it sets up a bi-directional tunnel with
   MA2, and generates RA messages with c-RSU's context information.



Jeong, et al.          Expires September 29, 2019              [Page 10]


Internet-Draft        Vehicular Mobility Management           March 2019


   That is, n-RSU pretents to be a router belonging to Subnet1.  When
   the vehicle receives the RA from n-RSU, it can maintain its
   connection with its corresponding node (i.e., CN1).  Note that n-RSU
   also sends RA messages with its domain prefix called prefix2.  The
   vehicle configures another global IP address with prefix2, and can
   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
   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 handoff delay.

           Vehicle               c-RSU              n-RSU
              |                     |                  |
              |---------------------|                  |
              |c-RSU detects leaving|                  |
              |---------------------|                  |
              |                     |--------PBU------>|
              |                     |                  |
              |                     |===Bi-Dir Tunnel==|
              |                     |                  |
              |                     |<-------PBA-------|
              |                     |                  |
              |                     |                  |
              |(--------RS with Mobility Info-------->)|
              |                 [VMI]                  |
              |                                        |
              |<--------RA with prefix1 (c-RSU)--------|
              |                                        |
              |<--------RA with prefix2 (n-RSU)--------|
              |                                        |

    Figure 6: Handoff of a Vehicle within Multiple Prefix Domains with
                                    DMM

   Figure 6 shows the handoff of a vehicle within two prefix domains (as
   two multi-link subnets) with DMM [I-D.DMM-PMIPv6].  If c-RSU detects
   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
   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
   information (e.g., c-RSU's link-local address and prefix called
   prefix1), and the vehicle's context information (e.g., the vehicle's
   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-
   directional tunnel with c-RSU, and generates RA messages with c-RSU's



Jeong, et al.          Expires September 29, 2019              [Page 11]


Internet-Draft        Vehicular Mobility Management           March 2019


   context information.  That is, n-RSU pretends to be a router
   belonging to Subnet1.  When the vehicle receives the RA from n-RSU,
   it can maintain its connection with its corresponding node (i.e.,
   CN1).  Note that n-RSU also sends RA messages with its domain prefix
   called prefix2.  The vehicle configures another global IP address
   with prefix2, and can use it for the communication with neighboring
   vehicles under the coverage of n-RSU.

6.  Security Considerations

   This document shares all the security issues of Vehicular ND
   [I-D.IPWAVE-VND], Proxy MIPv6 [RFC5213], and DMM
   [RFC7333][RFC7429][I-D.DMM-PMIPv6].

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., and K.
              Chowdhury, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC7333]  Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
              "Requirements for Distributed Mobility Management",
              RFC 7333, August 2014.

   [RFC7429]  Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ.
              Bernardos, "Distributed Mobility Management: Current
              Practices and Gap Analysis", RFC 7429, January 2015.

7.2.  Informative References








Jeong, et al.          Expires September 29, 2019              [Page 12]


Internet-Draft        Vehicular Mobility Management           March 2019


   [I-D.DMM-PMIPv6]
              Bernardos, CJ., Oliva, A., Giust, F., Zuniga, JC., and A.
              Mourad, "Proxy Mobile IPv6 extensions for Distributed
              Mobility Management", draft-ietf-dmm-pmipv6-dlif-04 (work
              in progress), January 2019.

   [I-D.IPWAVE-PS]
              Jeong, J., Ed., "IP Wireless Access in Vehicular
              Environments (IPWAVE): Problem Statement and Use Cases",
              draft-ietf-ipwave-vehicular-networking-08 (work in
              progress), March 2019.

   [I-D.IPWAVE-VND]
              Jeong, J., Ed., Shen, Y., and Z. Xiang, "IPv6 Neighbor
              Discovery for IP-Based Vehicular Networks", draft-jeong-
              ipwave-vehicular-neighbor-discovery-06 (work in progress),
              March 2019.

   [IEEE-802.11-OCB]
              "Part 11: Wireless LAN Medium Access Control (MAC) and
              Physical Layer (PHY) Specifications", IEEE Std
              802.11-2016, December 2016.

   [TS-23.285-3GPP]
              3GPP, "Architecture Enhancements for V2X Services", 3GPP
              TS 23.285, June 2018.

   [VIP-WAVE]
              Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the
              Feasibility of IP Communications in 802.11p Vehicular
              Networks", IEEE Transactions on Intelligent Transportation
              Systems, vol. 14, no. 1, March 2013.

   [WAVE-1609.0]
              IEEE 1609 Working Group, "IEEE Guide for Wireless Access
              in Vehicular Environments (WAVE) - Architecture", IEEE Std
              1609.0-2013, March 2014.














Jeong, et al.          Expires September 29, 2019              [Page 13]


Internet-Draft        Vehicular Mobility Management           March 2019


Appendix A.  Acknowledgments

   This work was supported by Basic Science Research Program through the
   National Research Foundation of Korea (NRF) funded by the Ministry of
   Education (2017R1D1A1B03035885).

Authors' Addresses

   Jaehoon Paul Jeong
   Department of Software
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 31 299 4957
   Fax:   +82 31 290 7996
   EMail: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php


   Yiwen Chris Shen
   Department of Electrical and Computer Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 31 299 4106
   Fax:   +82 31 290 7996
   EMail: chrisshen@skku.edu


   Zhong Xiang
   Department of Electrical and Computer Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 10 9895 1211
   Fax:   +82 31 290 7996
   EMail: xz618@skku.edu








Jeong, et al.          Expires September 29, 2019              [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/