draft-ietf-ipwave-vehicular-networking-15.txt   draft-ietf-ipwave-vehicular-networking-16.txt 
IPWAVE Working Group J. Jeong, Ed. IPWAVE Working Group J. Jeong, Ed.
Internet-Draft Sungkyunkwan University Internet-Draft Sungkyunkwan University
Intended status: Informational June 29, 2020 Intended status: Informational July 7, 2020
Expires: December 31, 2020 Expires: January 8, 2021
IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem
Statement and Use Cases Statement and Use Cases
draft-ietf-ipwave-vehicular-networking-15 draft-ietf-ipwave-vehicular-networking-16
Abstract Abstract
This document discusses the problem statement and use cases of This document discusses the problem statement and use cases of
IPv6-based vehicular networking for Intelligent Transportation IPv6-based vehicular networking for Intelligent Transportation
Systems (ITS). The main scenarios of vehicular communications are Systems (ITS). The main scenarios of vehicular communications are
vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and
vehicle-to-everything (V2X) communications. First, this document vehicle-to-everything (V2X) communications. First, this document
explains use cases using V2V, V2I, and V2X networking. Next, for explains use cases using V2V, V2I, and V2X networking. Next, for
IPv6-based vehicular networks, it makes a gap analysis of current IPv6-based vehicular networks, it makes a gap analysis of current
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2020. This Internet-Draft will expire on January 8, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 11 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 11
4.1. Vehicular Network Architecture . . . . . . . . . . . . . 11 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 12
4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 16 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 16
4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 18 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 19
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 20 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 21 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 21
5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 22 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 22
5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 24 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 24
5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 25 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 25 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. Informative References . . . . . . . . . . . . . . . . . . . 29 7. Informative References . . . . . . . . . . . . . . . . . . . 29
Appendix A. Changes from draft-ietf-ipwave-vehicular- Appendix A. Changes from draft-ietf-ipwave-vehicular-
networking-14 . . . . . . . . . . . . . . . . . . . 36 networking-15 . . . . . . . . . . . . . . . . . . . 36
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 36 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 36
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 36 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Vehicular networking studies have mainly focused on improving safety Vehicular networking studies have mainly focused on improving safety
and efficiency, and also enabling entertainment in vehicular and efficiency, and also enabling entertainment in vehicular
networks. The Federal Communications Commission (FCC) in the US networks. The Federal Communications Commission (FCC) in the US
allocated wireless channels for Dedicated Short-Range Communications allocated wireless channels for Dedicated Short-Range Communications
(DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with (DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with
the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). DSRC- the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). DSRC-
based wireless communications can support vehicle-to-vehicle (V2V), based wireless communications can support vehicle-to-vehicle (V2V),
skipping to change at page 3, line 30 skipping to change at page 3, line 30
and V2X in 5G mobile networks (called 5G V2X) [TS-23.285-3GPP] and V2X in 5G mobile networks (called 5G V2X) [TS-23.285-3GPP]
[TR-22.886-3GPP][TS-23.287-3GPP]. With C-V2X, vehicles can directly [TR-22.886-3GPP][TS-23.287-3GPP]. With C-V2X, vehicles can directly
communicate with each other without relay nodes (e.g., eNodeB in LTE communicate with each other without relay nodes (e.g., eNodeB in LTE
and gNodeB in 5G). and gNodeB in 5G).
Along with these WAVE standards and C-V2X standards, regardless of a Along with these WAVE standards and C-V2X standards, regardless of a
wireless access technology under the IP stack of a vehicle, vehicular wireless access technology under the IP stack of a vehicle, vehicular
networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6 networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6
protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6) protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6)
[RFC5213], Distributed Mobility Management (DMM) [RFC7333], Locator/ [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Locator/
ID Separation Protocol (LISP) [RFC6830], and Asymmetric Extended ID Separation Protocol (LISP) [RFC6830BIS], and Asymmetric Extended
Route Optimization (AERO) [RFC6706]). In addition, ISO has approved Route Optimization (AERO) [RFC6706BIS]). In addition, ISO has
a standard specifying the IPv6 network protocols and services to be approved a standard specifying the IPv6 network protocols and
used for Communications Access for Land Mobiles (CALM) [ISO-ITS-IPv6] services to be used for Communications Access for Land Mobiles (CALM)
[ISO-ITS-IPv6-AMD1]. [ISO-ITS-IPv6] [ISO-ITS-IPv6-AMD1].
This document describes use cases and a problem statement about This document describes use cases and a problem statement about
IPv6-based vehicular networking for ITS, which is named IPv6 Wireless IPv6-based vehicular networking for ITS, which is named IPv6 Wireless
Access in Vehicular Environments (IPWAVE). First, it introduces the Access in Vehicular Environments (IPWAVE). First, it introduces the
use cases for using V2V, V2I, and V2X networking in ITS. Next, for use cases for using V2V, V2I, and V2X networking in ITS. Next, for
IPv6-based vehicular networks, it makes a gap analysis of current IPv6-based vehicular networks, it makes a gap analysis of current
IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management,
and Security & Privacy), and then lists up requirements for the and Security & Privacy), and then lists up requirements for the
extensions of those IPv6 protocols, which are tailored to IPv6-based extensions of those IPv6 protocols, which are tailored to IPv6-based
vehicular networking. Thus, this document is intended to motivate vehicular networking. Thus, this document is intended to motivate
skipping to change at page 7, line 30 skipping to change at page 7, line 30
3.1. V2V 3.1. V2V
The use cases of V2V networking discussed in this section include The use cases of V2V networking discussed in this section include
o Context-aware navigation for safe driving and collision avoidance; o Context-aware navigation for safe driving and collision avoidance;
o Cooperative adaptive cruise control in a roadway; o Cooperative adaptive cruise control in a roadway;
o Platooning in a highway; o Platooning in a highway;
o Cooperative environment sensing. o Cooperative environment sensing;
These four techniques will be important elements for self-driving o Collision avoidance service of end systems of Urban Air Mobility
vehicles. (UAM).
These five techniques will be important elements for autonomous
vehicles, which may be either terrestrial vehicles or UAM end
systems.
Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers
to drive safely by alerting them to dangerous obstacles and to drive safely by alerting them to dangerous obstacles and
situations. That is, a CASD navigator displays obstacles or situations. That is, a CASD navigator displays obstacles or
neighboring vehicles relevant to possible collisions in real-time neighboring vehicles relevant to possible collisions in real-time
through V2V networking. CASD provides vehicles with a class-based through V2V networking. CASD provides vehicles with a class-based
automatic safety action plan, which considers three situations, automatic safety action plan, which considers three situations,
namely, the Line-of-Sight unsafe, Non-Line-of-Sight unsafe, and safe namely, the Line-of-Sight unsafe, Non-Line-of-Sight unsafe, and safe
situations. This action plan can be put into action among multiple situations. This action plan can be put into action among multiple
vehicles using V2V networking. vehicles using V2V networking.
skipping to change at page 8, line 35 skipping to change at page 8, line 39
Through cooperative environment sensing, driver-operated vehicles can Through cooperative environment sensing, driver-operated vehicles can
use environmental information sensed by driverless vehicles for use environmental information sensed by driverless vehicles for
better interaction with the other vehicles and environment. Vehicles better interaction with the other vehicles and environment. Vehicles
can also share their intended maneuvering information (e.g., lane can also share their intended maneuvering information (e.g., lane
change, speed change, ramp in-and-out, cut-in, and abrupt braking) change, speed change, ramp in-and-out, cut-in, and abrupt braking)
with neighboring vehicles. Thus, this information sharing can help with neighboring vehicles. Thus, this information sharing can help
the vehicles behave as more efficient traffic flows and minimize the vehicles behave as more efficient traffic flows and minimize
unnecessary acceleration and deceleration to achieve the best ride unnecessary acceleration and deceleration to achieve the best ride
comfort. comfort.
A collision avoidance service of UAM end systems in air can be
envisioned as a use case in air vehicular environments. This use
case is similar to the context-aware navigator for terrestrial
vehicles. Through V2V coordination, those UAM end systems (e.g.,
drones) can avoid a dangerous situation (e.g., collision) in three-
dimensional space rather than two-dimensional space for terrestrial
vehicles. Also, UAM end systems (e.g., flying car) with only a few
meters off the ground can communicate with terrestrial vehicles with
wireless communication technologies (e.g., DSRC, LTE, and C-V2X).
Thus, V2V means any vehicle to any vehicle, whether the vehicles are
ground-level or not.
To encourage more vehicles to participate in this cooperative To encourage more vehicles to participate in this cooperative
environmental sensing, a reward system will be needed. Sensing environmental sensing, a reward system will be needed. Sensing
activities of each vehicle need to be logged in either a central way activities of each vehicle need to be logged in either a central way
through a logging server (e.g., TCC) in the vehicular cloud or a through a logging server (e.g., TCC) in the vehicular cloud or a
distributed way (e.g., blockchain [Bitcoin]) through other vehicles distributed way (e.g., blockchain [Bitcoin]) through other vehicles
or infrastructure. In the case of a blockchain, each sensing message or infrastructure. In the case of a blockchain, each sensing message
from a vehicle can be treated as a transaction and the neighboring from a vehicle can be treated as a transaction and the neighboring
vehicles can play the role of peers in a consensus method of a vehicles can play the role of peers in a consensus method of a
blockchain such as Proof of Work (PoW) and Proof of Stake (PoS) blockchain [Bitcoin][Vehicular-BlockChain].
[Bitcoin][Vehicular-BlockChain].
The existing IPv6 protocol does not support wireless single-hop V2V The existing IPv6 protocol does not support wireless single-hop V2V
communications as well as wireless multihop V2V communications. communications as well as wireless multihop V2V communications.
Thus, the IPv6 needs to support both single-hop and multihop Thus, the IPv6 needs to support both single-hop and multihop
communications in a wireless medium so that vehicles can communicate communications in a wireless medium so that vehicles can communicate
with each other by V2V communications to share either an emergency with each other by V2V communications to share either an emergency
situation or road hazard in a highway. situation or road hazard in a highway.
To support applications of these V2V use cases, the functions of IPv6 To support applications of these V2V use cases, the functions of IPv6
such as VND and VSP are prerequisites for IPv6-based packet exchange such as VND and VSP are prerequisites for IPv6-based packet exchange
skipping to change at page 9, line 19 skipping to change at page 9, line 36
3.2. V2I 3.2. V2I
The use cases of V2I networking discussed in this section include The use cases of V2I networking discussed in this section include
o Navigation service; o Navigation service;
o Energy-efficient speed recommendation service; o Energy-efficient speed recommendation service;
o Accident notification service; o Accident notification service;
o Electric vehicle (EV) charging service. o Electric vehicle (EV) charging service;
o UAM navigation service with efficient battery charging.
A navigation service, for example, the Self-Adaptive Interactive A navigation service, for example, the Self-Adaptive Interactive
Navigation Tool(SAINT) [SAINT], using V2I networking interacts with a Navigation Tool(SAINT) [SAINT], using V2I networking interacts with a
TCC for the large-scale/long-range road traffic optimization and can TCC for the large-scale/long-range road traffic optimization and can
guide individual vehicles along appropriate navigation paths in real guide individual vehicles along appropriate navigation paths in real
time. The enhanced version of SAINT [SAINTplus] can give fast moving time. The enhanced version of SAINT [SAINTplus] can give fast moving
paths to emergency vehicles (e.g., ambulance and fire engine) to let paths to emergency vehicles (e.g., ambulance and fire engine) to let
them reach an accident spot while redirecting other vehicles near the them reach an accident spot while redirecting other vehicles near the
accident spot into efficient detour paths. accident spot into efficient detour paths.
skipping to change at page 10, line 16 skipping to change at page 10, line 34
An EV charging service with V2I can facilitates the efficient battery An EV charging service with V2I can facilitates the efficient battery
charging of EVs. In the case where an EV charging station is charging of EVs. In the case where an EV charging station is
connected to an IP-RSU, an EV can be guided toward the deck of the EV connected to an IP-RSU, an EV can be guided toward the deck of the EV
charging station through a battery charging server connected to the charging station through a battery charging server connected to the
IP-RSU. In addition to this EV charging service, other value-added IP-RSU. In addition to this EV charging service, other value-added
services (e.g., air firmware/software update and media streaming) can services (e.g., air firmware/software update and media streaming) can
be provided to an EV while it is charging its battery at the EV be provided to an EV while it is charging its battery at the EV
charging station. charging station.
A UAM navigation service with efficient battery charging can make the
battery charging schedule of UAM end systems (e.g., drone) for long-
distance flying [CBDN]. For this battery charging schedule, a UAM
end system can communicate with an infrastructure node (e.g., IP-RSU)
toward a cloud server via V2I communications. This cloud server can
coordinate the battery charging schedules of multiple UAM end systems
for their efficient navigation path, considering flight time from
their current position to a battery charging station, waiting time in
a waiting queue at the station, and battery charging time at the
station.
The existing IPv6 protocol does not support wireless multihop V2I The existing IPv6 protocol does not support wireless multihop V2I
communications in a highway where RSUs are sparsely deployed, so a communications in a highway where RSUs are sparsely deployed, so a
vehicle can reach the wireless coverage of an RSU through the vehicle can reach the wireless coverage of an RSU through the
multihop data forwarding of intermediate vehicles. Thus, IPv6 needs multihop data forwarding of intermediate vehicles. Thus, IPv6 needs
to be extended for multihop V2I communications. to be extended for multihop V2I communications.
To support applications of these V2I use cases, the functions of IPv6 To support applications of these V2I use cases, the functions of IPv6
such as VND, VMM, and VSP are prerequisites for IPv6-based packet such as VND, VMM, and VSP are prerequisites for IPv6-based packet
exchange, transport-layer session continuity, and secure, safe exchange, transport-layer session continuity, and secure, safe
communication between a vehicle and a server in the vehicular cloud. communication between a vehicle and a server in the vehicular cloud.
skipping to change at page 11, line 25 skipping to change at page 12, line 7
4. Vehicular Networks 4. Vehicular Networks
This section describes an example vehicular network architecture This section describes an example vehicular network architecture
supporting V2V, V2I, and V2X communications in vehicular networks. supporting V2V, V2I, and V2X communications in vehicular networks.
It describes an internal network within a vehicle or an edge network It describes an internal network within a vehicle or an edge network
(called EN). It explains not only the internetworking between the (called EN). It explains not only the internetworking between the
internal networks of a vehicle and an EN via wireless links, but also internal networks of a vehicle and an EN via wireless links, but also
the internetworking between the internal networks of two vehicles via the internetworking between the internal networks of two vehicles via
wireless links. wireless links.
4.1. Vehicular Network Architecture
Figure 1 shows an example vehicular network architecture for V2I and
V2V in a road network [OMNI-Interface]. The vehicular network
architecture contains vehicles (including IP-OBU), IP-RSUs, Mobility
Anchor, Traffic Control Center, and Vehicular Cloud as components.
Note that the components of the vehicular network architecture can be
mapped to those of an IP-based aeronautical network architecture in
[OMNI-Interface], as shown in Figure 2.
Traffic Control Center in Vehicular Cloud Traffic Control Center in Vehicular Cloud
******************************************* *******************************************
+-------------+ * * +-------------+ * *
|Corresponding| * +-----------------+ * |Corresponding| * +-----------------+ *
| Node |<->* | Mobility Anchor | * | Node |<->* | Mobility Anchor | *
+-------------+ * +-----------------+ * +-------------+ * +-----------------+ *
* ^ * * ^ *
* | * * | *
* v * * v *
******************************************* *******************************************
skipping to change at page 13, line 4 skipping to change at page 12, line 45
| +--------+ | | +--------+ | | +--------+ | | +--------+ | | +--------+ | | +--------+ |
| |Vehicle5|===> | | |Vehicle6|===>| | |Vehicle7|==>| | |Vehicle5|===> | | |Vehicle6|===>| | |Vehicle7|==>|
| +--------+ | | +--------+ | | +--------+ | | +--------+ | | +--------+ | | +--------+ |
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
Subnet1 Subnet2 Subnet3 Subnet1 Subnet2 Subnet3
(Prefix1) (Prefix2) (Prefix3) (Prefix1) (Prefix2) (Prefix3)
<----> Wired Link <....> Wireless Link ===> Moving Direction <----> Wired Link <....> Wireless Link ===> Moving Direction
Figure 1: An Example Vehicular Network Architecture for V2I and V2V Figure 1: An Example Vehicular Network Architecture for V2I and V2V
4.1. Vehicular Network Architecture
Figure 1 shows an example vehicular network architecture for V2I and
V2V in a road network [OMNI-Interface]. The vehicular network
architecture contains vehicles (including IP-OBU), IP-RSUs, Mobility
Anchor, Traffic Control Center, and Vehicular Cloud as components.
Note that the components of the vehicular network architecture can be
mapped to those of an IP-based aeronautical network architecture in
[OMNI-Interface], as shown in Figure 2.
+-------------------+------------------------------------+ +-------------------+------------------------------------+
| Vehicular Network | Aeronautical Network | | Vehicular Network | Aeronautical Network |
+===================+====================================+ +===================+====================================+
| IP-RSU | Access Router (AR) | | IP-RSU | Access Router (AR) |
+-------------------+------------------------------------+ +-------------------+------------------------------------+
| Vehicle (IP-OBU) | Mobile Node (MN) | | Vehicle (IP-OBU) | Mobile Node (MN) |
+-------------------+------------------------------------+ +-------------------+------------------------------------+
| Moving Network | End User Network (EUN) | | Moving Network | End User Network (EUN) |
+-------------------+------------------------------------+ +-------------------+------------------------------------+
| Mobility Anchor | Mobility Service Endpoint (MSE) | | Mobility Anchor | Mobility Service Endpoint (MSE) |
skipping to change at page 13, line 28 skipping to change at page 13, line 33
Figure 2: Mapping between Vehicular Network Components and Figure 2: Mapping between Vehicular Network Components and
Aeronautical Network Components Aeronautical Network Components
These components are not mandatory, and they can be deployed into These components are not mandatory, and they can be deployed into
vehicular networks in various ways. Some of them (e.g., Mobility vehicular networks in various ways. Some of them (e.g., Mobility
Anchor, Traffic Control Center, and Vehicular Cloud) may not be Anchor, Traffic Control Center, and Vehicular Cloud) may not be
needed for the vehicular networks according to target use cases in needed for the vehicular networks according to target use cases in
Section 3. Section 3.
An existing network architecture (e.g., an IP-based aeronautical An existing network architecture (e.g., an IP-based aeronautical
network architecture [OMNI-Interface], a network architecture of network architecture [OMNI-Interface][UAM-ITS], a network
PMIPv6 [RFC5213], and a low-power and lossy network architecture architecture of PMIPv6 [RFC5213], and a low-power and lossy network
[RFC6550]) can be extended to a vehicular network architecture for architecture [RFC6550]) can be extended to a vehicular network
multihop V2V, V2I, and V2X, as shown in Figure 1. In a highway architecture for multihop V2V, V2I, and V2X, as shown in Figure 1.
scenario, a vehicle may not access an RSU directly because of the In a highway scenario, a vehicle may not access an RSU directly
distance of the DSRC coverage (up to 1 km). For example, RPL (IPv6 because of the distance of the DSRC coverage (up to 1 km). For
Routing Protocol for Low-Power and Lossy Networks) [RFC6550] can be example, RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
extended to support a multihop V2I since a vehicle can take advantage [RFC6550] can be extended to support a multihop V2I since a vehicle
of other vehicles as relay nodes to reach the RSU. Also, RPL can be can take advantage of other vehicles as relay nodes to reach the RSU.
extended to support both multihop V2V and V2X in the similar way. Also, RPL can be extended to support both multihop V2V and V2X in the
similar way.
Wireless communications needs to be considered for end systems for
Urban Air Mobility (UAM) such as flying cars and taxis [UAM-ITS].
These UAM end systems may have multiple wireless transmission media
interfaces (e.g., cellular, communications satellite (SATCOM), short-
range omni-directional interfaces), which are offered by different
data link service providers. To support not only the mobility
management of the UAM end systems, but also the multihop and
multilink communications of the UAM interfaces, the UAM end systems
can employ an Overlay Multilink Network (OMNI) interface
[OMNI-Interface] as a virtual Non-Broadcast Multiple Access (NBMA)
connection to a serving ground domain infrastructure. This
infrastructure can be configured over the underlying data links. The
OMNI interface and its link model provide a means of multilink,
multihop and mobility coordination to the legacy IPv6 ND messaging
[RFC4861] according to the NBMA principle. Thus, the OMNI link model
can support efficient UAM internetworking services without additional
mobility messaging, and without any modification to the IPv6 ND
messaging services or link model.
As shown in this figure, IP-RSUs as routers and vehicles with IP-OBU As shown in this figure, IP-RSUs as routers and vehicles with IP-OBU
have wireless media interfaces for VANET. Furthermore, the wireless have wireless media interfaces for VANET. Furthermore, the wireless
media interfaces are autoconfigured with a global IPv6 prefix (e.g., media interfaces are autoconfigured with a global IPv6 prefix (e.g.,
2001:DB8:1:1::/64) to support both V2V and V2I networking. Note that 2001:DB8:1:1::/64) to support both V2V and V2I networking. Note that
2001:DB8::/32 is a documentation prefix [RFC3849] for example 2001:DB8::/32 is a documentation prefix [RFC3849] for example
prefixes in this document, and also that any routable IPv6 address prefixes in this document, and also that any routable IPv6 address
needs to be routable in a VANET and a vehicular network including IP- needs to be routable in a VANET and a vehicular network including IP-
RSUs. RSUs.
skipping to change at page 16, line 42 skipping to change at page 17, line 18
A vehicle's internal network often uses Ethernet to interconnect A vehicle's internal network often uses Ethernet to interconnect
Electronic Control Units (ECUs) in the vehicle. The internal network Electronic Control Units (ECUs) in the vehicle. The internal network
can support Wi-Fi and Bluetooth to accommodate a driver's and can support Wi-Fi and Bluetooth to accommodate a driver's and
passenger's mobile devices (e.g., smartphone or tablet). The network passenger's mobile devices (e.g., smartphone or tablet). The network
topology and subnetting depend on each vendor's network configuration topology and subnetting depend on each vendor's network configuration
for a vehicle and an EN. It is reasonable to consider the for a vehicle and an EN. It is reasonable to consider the
interaction between the internal network and an external network interaction between the internal network and an external network
within another vehicle or an EN. within another vehicle or an EN.
As shown in Figure 3, as internal networks, a vehicle's moving
network and an EN's fixed network are self-contained networks having
multiple subnets and having an edge router (e.g., IP-OBU and IP-RSU)
for the communication with another vehicle or another EN. The
internetworking between two internal networks via V2I communication
requires the exchange of the network parameters and the network
prefixes of the internal networks. For the efficiency, the network
prefixes of the internal networks (as a moving network) in a vehicle
need to be delegated and configured automatically. Note that a
moving network's network prefix can be called a Mobile Network Prefix
(MNP) [OMNI-Interface].
+-----------------+ +-----------------+
(*)<........>(*) +----->| Vehicular Cloud | (*)<........>(*) +----->| Vehicular Cloud |
2001:DB8:1:1::/64 | | | +-----------------+ 2001:DB8:1:1::/64 | | | +-----------------+
+------------------------------+ +---------------------------------+ +------------------------------+ +---------------------------------+
| v | | v v | | v | | v v |
| +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ |
| | Host1 | |IP-OBU1| | | |IP-RSU1| | Host3 | | | | Host1 | |IP-OBU1| | | |IP-RSU1| | Host3 | |
| +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ |
| ^ ^ | | ^ ^ | | ^ ^ | | ^ ^ |
| | | | | | | | | | | | | | | |
skipping to change at page 17, line 37 skipping to change at page 17, line 48
| 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) EN1 (Fixed Network1) Vehicle1 (Moving Network1) EN1 (Fixed Network1)
<----> Wired Link <....> Wireless Link (*) Antenna <----> Wired Link <....> Wireless Link (*) Antenna
Figure 3: Internetworking between Vehicle and Edge Network Figure 3: Internetworking between Vehicle and Edge Network
As shown in Figure 3, as internal networks, a vehicle's moving
network and an EN's fixed network are self-contained networks having
multiple subnets and having an edge router (e.g., IP-OBU and IP-RSU)
for the communication with another vehicle or another EN. The
internetworking between two internal networks via V2I communication
requires the exchange of the network parameters and the network
prefixes of the internal networks. For the efficiency, the network
prefixes of the internal networks (as a moving network) in a vehicle
need to be delegated and configured automatically. Note that a
moving network's network prefix can be called a Mobile Network Prefix
(MNP) [OMNI-Interface].
Figure 3 also shows the internetworking between the vehicle's moving Figure 3 also shows the internetworking between the vehicle's moving
network and the EN's fixed network. There exists an internal network network and the EN's fixed network. There exists an internal network
(Moving Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and (Moving Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and
Host2), and two routers (IP-OBU1 and Router1). There exists another Host2), and two routers (IP-OBU1 and Router1). There exists another
internal network (Fixed Network1) inside EN1. EN1 has one host internal network (Fixed Network1) inside EN1. EN1 has one host
(Host3), two routers (IP-RSU1 and Router2), and the collection of (Host3), two routers (IP-RSU1 and Router2), and the collection of
servers (Server1 to ServerN) for various services in the road servers (Server1 to ServerN) for various services in the road
networks, such as the emergency notification and navigation. networks, such as the emergency notification and navigation.
Vehicle1's IP-OBU1 (as a mobile router) and EN1's IP-RSU1 (as a fixed Vehicle1's IP-OBU1 (as a mobile router) and EN1's IP-RSU1 (as a fixed
router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for
skipping to change at page 18, line 35 skipping to change at page 19, line 10
uniqueness of an IPv6 address, the configuration and control overhead uniqueness of an IPv6 address, the configuration and control overhead
of the DAD of the wireless link interfaces should be minimized to of the DAD of the wireless link interfaces should be minimized to
support the V2I and V2X communications of vehicles moving fast along support the V2I and V2X communications of vehicles moving fast along
roadways. roadways.
4.3. V2V-based Internetworking 4.3. V2V-based Internetworking
This section discusses the internetworking between the moving This section discusses the internetworking between the moving
networks of two neighboring vehicles via V2V communication. networks of two neighboring vehicles via V2V communication.
Figure 4 shows the internetworking between the moving networks of two
neighboring vehicles. There exists an internal network (Moving
Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and Host2),
and two routers (IP-OBU1 and Router1). There exists another internal
network (Moving Network2) inside Vehicle2. Vehicle2 has two hosts
(Host3 and Host4), and two routers (IP-OBU2 and Router2). Vehicle1's
IP-OBU1 (as a mobile router) and Vehicle2's IP-OBU2 (as a mobile
router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for
V2V networking. Thus, a host (Host1) in Vehicle1 can communicate
with another host (Host3) in Vehicle2 for a vehicular service through
Vehicle1's moving network, a wireless link between IP-OBU1 and IP-
OBU2, and Vehicle2's moving network.
(*)<..........>(*) (*)<..........>(*)
2001:DB8:1:1::/64 | | 2001:DB8:1:1::/64 | |
+------------------------------+ +------------------------------+ +------------------------------+ +------------------------------+
| v | | v | | v | | v |
| +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ |
| | Host1 | |IP-OBU1| | | |IP-OBU2| | Host3 | | | | Host1 | |IP-OBU1| | | |IP-OBU2| | Host3 | |
| +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ | | +-------+ +-------+ |
| ^ ^ | | ^ ^ | | ^ ^ | | ^ ^ |
| | | | | | | | | | | | | | | |
| v v | | v v | | v v | | v v |
skipping to change at page 19, line 34 skipping to change at page 19, line 39
| v v | | v v | | v v | | v v |
| ---------------------------- | | ---------------------------- | | ---------------------------- | | ---------------------------- |
| 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 | | 2001:DB8:10:2::/64 | | 2001:DB8:30:2::/64 |
+------------------------------+ +------------------------------+ +------------------------------+ +------------------------------+
Vehicle1 (Moving Network1) Vehicle2 (Moving Network2) Vehicle1 (Moving Network1) Vehicle2 (Moving Network2)
<----> Wired Link <....> Wireless Link (*) Antenna <----> Wired Link <....> Wireless Link (*) Antenna
Figure 4: Internetworking between Two Vehicles Figure 4: Internetworking between Two Vehicles
Figure 4 shows the internetworking between the moving networks of two
neighboring vehicles. There exists an internal network (Moving
Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and Host2),
and two routers (IP-OBU1 and Router1). There exists another internal
network (Moving Network2) inside Vehicle2. Vehicle2 has two hosts
(Host3 and Host4), and two routers (IP-OBU2 and Router2). Vehicle1's
IP-OBU1 (as a mobile router) and Vehicle2's IP-OBU2 (as a mobile
router) use 2001:DB8:1:1::/64 for an external link (e.g., DSRC) for
V2V networking. Thus, a host (Host1) in Vehicle1 can communicate
with another host (Host3) in Vehicle2 for a vehicular service through
Vehicle1's moving network, a wireless link between IP-OBU1 and IP-
OBU2, and Vehicle2's moving network.
As a V2V use case in Section 3.1, Figure 5 shows the linear network As a V2V use case in Section 3.1, Figure 5 shows the linear network
topology of platooning vehicles for V2V communications where Vehicle3 topology of platooning vehicles for V2V communications where Vehicle3
is the leading vehicle with a driver, and Vehicle2 and Vehicle1 are is the leading vehicle with a driver, and Vehicle2 and Vehicle1 are
the following vehicles without drivers. the following vehicles without drivers.
(*)<..................>(*)<..................>(*) (*)<..................>(*)<..................>(*)
| | | | | |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | | | | | |
| +-------+ | | +-------+ | | +-------+ | | +-------+ | | +-------+ | | +-------+ |
skipping to change at page 27, line 25 skipping to change at page 27, line 29
Even though vehicles can be authenticated with valid certificates by Even though vehicles can be authenticated with valid certificates by
an authentication server in the vehicular cloud, the authenticated an authentication server in the vehicular cloud, the authenticated
vehicles may harm other vehicles, so their communication activities vehicles may harm other vehicles, so their communication activities
need to be logged in either a central way through a logging server need to be logged in either a central way through a logging server
(e.g., TCC) in the vehicular cloud or a distributed way (e.g., (e.g., TCC) in the vehicular cloud or a distributed way (e.g.,
blockchain [Bitcoin]) along with other vehicles or infrastructure. blockchain [Bitcoin]) along with other vehicles or infrastructure.
For the non-repudiation of the harmful activities of malicious nodes, For the non-repudiation of the harmful activities of malicious nodes,
a blockchain technology can be used [Bitcoin]. Each message from a a blockchain technology can be used [Bitcoin]. Each message from a
vehicle can be treated as a transaction and the neighboring vehicles vehicle can be treated as a transaction and the neighboring vehicles
can play the role of peers in a consensus method of a blockchain such can play the role of peers in a consensus method of a blockchain
as PoW and PoS [Bitcoin][Vehicular-BlockChain]. [Bitcoin][Vehicular-BlockChain]. For a blockchain's efficient
consensus in vehicular networks having fast moving vehicles, a new
consensus algorithm needs to be developed or an existing consensus
algorithm needs to be enhanced.
To identify malicious vehicles among vehicles, an authentication To identify malicious vehicles among vehicles, an authentication
method is required. A Vehicle Identification Number (VIN) and a user method is required. A Vehicle Identification Number (VIN) and a user
certificate (e.g., X.509 certificate [RFC5280]) along with an in- certificate (e.g., X.509 certificate [RFC5280]) along with an in-
vehicle device's identifier generation can be used to efficiently vehicle device's identifier generation can be used to efficiently
authenticate a vehicle or its driver (having a user certificate) authenticate a vehicle or its driver (having a user certificate)
through a road infrastructure node (e.g., IP-RSU) connected to an through a road infrastructure node (e.g., IP-RSU) connected to an
authentication server in the vehicular cloud. This authentication authentication server in the vehicular cloud. This authentication
can be used to identify the vehicle that will communicate with an can be used to identify the vehicle that will communicate with an
infrastructure node or another vehicle. In the case where a vehicle infrastructure node or another vehicle. In the case where a vehicle
skipping to change at page 29, line 33 skipping to change at page 29, line 42
Available: Available:
http://www.path.berkeley.edu/research/automated-and- http://www.path.berkeley.edu/research/automated-and-
connected-vehicles/cooperative-adaptive-cruise-control, connected-vehicles/cooperative-adaptive-cruise-control,
2017. 2017.
[CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A
Framework of Context-Awareness Safety Driving in Vehicular Framework of Context-Awareness Safety Driving in Vehicular
Networks", International Workshop on Device Centric Cloud Networks", International Workshop on Device Centric Cloud
(DC2), March 2016. (DC2), March 2016.
[CBDN] Kim, J., Kim, S., Jeong, J., Kim, H., Park, J., and T.
Kim, "CBDN: Cloud-Based Drone Navigation for Efficient
Battery Charging in Drone Networks", IEEE Transactions on
Intelligent Transportation Systems, November 2019.
[DMM-FPC] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., [DMM-FPC] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
Moses, D., and C. Perkins, "Protocol for Forwarding Policy Moses, D., and C. Perkins, "Protocol for Forwarding Policy
Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-13 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-13
(work in progress), March 2020. (work in progress), March 2020.
[DSRC] ASTM International, "Standard Specification for [DSRC] ASTM International, "Standard Specification for
Telecommunications and Information Exchange Between Telecommunications and Information Exchange Between
Roadside and Vehicle Systems - 5 GHz Band Dedicated Short Roadside and Vehicle Systems - 5 GHz Band Dedicated Short
Range Communications (DSRC) Medium Access Control (MAC) Range Communications (DSRC) Medium Access Control (MAC)
and Physical Layer (PHY) Specifications", and Physical Layer (PHY) Specifications",
skipping to change at page 32, line 46 skipping to change at page 33, line 10
2011. 2011.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011. Support in IPv6", RFC 6275, July 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012.
[RFC6706] Templin, F., "Asymmetric Extended Route Optimization [RFC6706BIS]
(AERO)", RFC 6706, August 2012. Templin, F., "Asymmetric Extended Route Optimization
(AERO)", draft-templin-intarea-6706bis-58 (work in
progress), June 2020.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012. November 2012.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830BIS]
Locator/ID Separation Protocol (LISP)", RFC 6830, January Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
2013. Cabellos, "The Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-rfc6830bis-32 (work in progress), March
2020.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider Networking: A Perspective from within a Service Provider
Environment", RFC 7149, March 2014. Environment", RFC 7149, March 2014.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol Version 2", "The Optimized Link State Routing Protocol Version 2",
RFC 7181, April 2014. RFC 7181, April 2014.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
skipping to change at page 34, line 41 skipping to change at page 35, line 10
[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/Version 16.2.0, December 2019. TS 23.285/Version 16.2.0, December 2019.
[TS-23.287-3GPP] [TS-23.287-3GPP]
3GPP, "Architecture Enhancements for 5G System (5GS) to 3GPP, "Architecture Enhancements for 5G System (5GS) to
Support Vehicle-to-Everything (V2X) Services", 3GPP Support Vehicle-to-Everything (V2X) Services", 3GPP
TS 23.287/Version 16.2.0, March 2020. TS 23.287/Version 16.2.0, March 2020.
[UAM-ITS] Templin, F., "Urban Air Mobility Implications for
Intelligent Transportation Systems", draft-templin-ipwave-
uam-its-03 (work in progress), July 2020.
[Vehicular-BlockChain] [Vehicular-BlockChain]
Dorri, A., Steger, M., Kanhere, S., and R. Jurdak, Dorri, A., Steger, M., Kanhere, S., and R. Jurdak,
"BlockChain: A Distributed Solution to Automotive Security "BlockChain: A Distributed Solution to Automotive Security
and Privacy", IEEE Communications Magazine, Vol. 55, No. and Privacy", IEEE Communications Magazine, Vol. 55, No.
12, December 2017. 12, December 2017.
[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
Networks", IEEE Transactions on Intelligent Transportation Networks", IEEE Transactions on Intelligent Transportation
skipping to change at page 36, line 5 skipping to change at page 36, line 5
[WAVE-1609.3] [WAVE-1609.3]
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-ietf-ipwave-vehicular-networking-14 Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-15
The following changes are made from draft-ietf-ipwave-vehicular- The following changes are made from draft-ietf-ipwave-vehicular-
networking-14: networking-15:
o This version is revised based on the comments from eight o This version is revised based on the further comments from the
reviewers: Nancy Cam-Winget (Cisco), Fred L. Templin (The Boeing following reviewers: Fred L. Templin (The Boeing Company) and
Company), Jung-Soo Park (ETRI), Zeungil (Ben) Kim (Hyundai YongJoon Joe (LSware).
Motors), Kyoungjae Sun (Soongsil University), Zhiwei Yan (CNNIC),
Yong-Joon Joe (LSware), and Peter E. Yee (Akayla). o According to the comments from Fred L. Templin, in Section 3.1
and Section 3.2, UAM (Urban Air Mobility) end systems are
considered for new V2V and V2I use cases.
o According to the comments from YongJoon Joe, in Section 3.1 and
Section 6, the text about a consensus method of a blockchain in
vehicular networks is revised such that a consensus algorithm
needs to be efficient for fast moving vehicles.
Appendix B. Acknowledgments Appendix B. Acknowledgments
This work was supported by Institute of Information & Communications This work was supported by Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea Technology Planning & Evaluation (IITP) grant funded by the Korea
MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based
Security Intelligence Technology Development for the Customized Security Intelligence Technology Development for the Customized
Security Service Provisioning). Security Service Provisioning).
This work was supported in part by the MSIT (Ministry of Science and This work was supported in part by the MSIT (Ministry of Science and
skipping to change at page 36, line 42 skipping to change at page 36, line 49
Appendix C. Contributors Appendix C. Contributors
This document is a group work of IPWAVE working group, greatly This document is a group work of IPWAVE working group, greatly
benefiting from inputs and texts by Rex Buddenberg (Naval benefiting from inputs and texts by Rex Buddenberg (Naval
Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest
University of Technology and Economics), Jose Santa Lozanoi University of Technology and Economics), Jose Santa Lozanoi
(Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot), (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot),
Sri Gundavelli (Cisco), Erik Nordmark, Dirk von Hugo (Deutsche Sri Gundavelli (Cisco), Erik Nordmark, Dirk von Hugo (Deutsche
Telekom), Pascal Thubert (Cisco), Carlos Bernardos (UC3M), Russ Telekom), Pascal Thubert (Cisco), Carlos Bernardos (UC3M), Russ
Housley (Vigil Security), and Suresh Krishnan (Kaloom). The authors Housley (Vigil Security), Suresh Krishnan (Kaloom), Nancy Cam-Winget
sincerely appreciate their contributions. (Cisco), Fred L. Templin (The Boeing Company), Jung-Soo Park (ETRI),
Zeungil (Ben) Kim (Hyundai Motors), Kyoungjae Sun (Soongsil
University), Zhiwei Yan (CNNIC), YongJoon Joe (LSware), and Peter E.
Yee (Akayla). The authors sincerely appreciate their contributions.
The following are co-authors of this document: The following are co-authors of this document:
Nabil Benamar Nabil Benamar
Department of Computer Sciences Department of Computer Sciences
High School of Technology of Meknes High School of Technology of Meknes
Moulay Ismail University Moulay Ismail University
Morocco Morocco
Phone: +212 6 70 83 22 36 Phone: +212 6 70 83 22 36
EMail: benamar73@gmail.com EMail: benamar73@gmail.com
Sandra Cespedes Sandra Cespedes
NIC Chile Research Labs NIC Chile Research Labs
Universidad de Chile Universidad de Chile
Av. Blanco Encalada 1975 Av. Blanco Encalada 1975
Santiago Santiago
Chile Chile
 End of changes. 32 change blocks. 
81 lines changed or deleted 158 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/