draft-ietf-ipwave-vehicular-networking-06.txt   draft-ietf-ipwave-vehicular-networking-07.txt 
IPWAVE Working Group J. Jeong, Ed. IPWAVE Working Group J. Jeong, Ed.
Internet-Draft Sungkyunkwan University Internet-Draft Sungkyunkwan University
Intended status: Informational October 22, 2018 Intended status: Informational November 4, 2018
Expires: April 25, 2019 Expires: May 8, 2019
IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement
and Use Cases and Use Cases
draft-ietf-ipwave-vehicular-networking-06 draft-ietf-ipwave-vehicular-networking-07
Abstract Abstract
This document discusses the problem statement and use cases on IP- This document discusses the problem statement and use cases on IP-
based vehicular networks, which are considered a key component of based vehicular networks, which are considered a key component of
Intelligent Transportation Systems (ITS). The main scenarios of Intelligent Transportation Systems (ITS). The main scenarios of
vehicular communications are vehicle-to-vehicle (V2V), vehicle-to- vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-
infrastructure (V2I), and vehicle-to-everything (V2X) communications. infrastructure (V2I), and vehicle-to-everything (V2X) communications.
First, this document surveys use cases using V2V, V2I, and V2X First, this document surveys use cases using V2V, V2I, and V2X
networking. Second, it analyzes proposed protocols for IP-based networking. Second, it analyzes proposed protocols for IP-based
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 April 25, 2019. This Internet-Draft will expire on May 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Analysis for Existing Protocols . . . . . . . . . . . . . . . 7 4. Analysis for Existing Protocols . . . . . . . . . . . . . . . 8
4.1. Existing Protocols for Vehicular Networking . . . . . . . 8 4.1. Existing Protocols for Vehicular Networking . . . . . . . 8
4.1.1. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . 8 4.1.1. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . 8
4.1.2. IP Address Autoconfiguration . . . . . . . . . . . . 8 4.1.2. IP Address Autoconfiguration . . . . . . . . . . . . 8
4.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.4. Mobility Management . . . . . . . . . . . . . . . . . 9 4.1.4. Mobility Management . . . . . . . . . . . . . . . . . 9
4.1.5. DNS Naming Service . . . . . . . . . . . . . . . . . 9 4.1.5. DNS Naming Service . . . . . . . . . . . . . . . . . 9
4.1.6. Service Discovery . . . . . . . . . . . . . . . . . . 9 4.1.6. Service Discovery . . . . . . . . . . . . . . . . . . 9
4.1.7. Security and Privacy . . . . . . . . . . . . . . . . 10 4.1.7. Security and Privacy . . . . . . . . . . . . . . . . 10
4.2. General Problems . . . . . . . . . . . . . . . . . . . . 10 4.2. General Problems . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Vehicular Network Architecture . . . . . . . . . . . 11 4.2.1. Vehicular Network Architecture . . . . . . . . . . . 11
4.2.2. Latency . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.2. Latency . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 15 4.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4. Pseudonym Handling . . . . . . . . . . . . . . . . . 15 4.2.4. Pseudonym Handling . . . . . . . . . . . . . . . . . 16
5. Problem Exploration . . . . . . . . . . . . . . . . . . . . . 16 5. Problem Exploration . . . . . . . . . . . . . . . . . . . . . 17
5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 16 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 17
5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 17 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 18
5.1.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 17 5.1.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 18
5.1.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 17 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 19
5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 18 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Informative References . . . . . . . . . . . . . . . . . . . 19 7. Informative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Relevant Topics to IPWAVE Working Group . . . . . . 27 Appendix A. Relevant Topics to IPWAVE Working Group . . . . . . 29
A.1. Vehicle Identity Management . . . . . . . . . . . . . . . 27 A.1. Vehicle Identity Management . . . . . . . . . . . . . . . 29
A.2. Multihop V2X . . . . . . . . . . . . . . . . . . . . . . 27 A.2. Multihop V2X . . . . . . . . . . . . . . . . . . . . . . 29
A.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 27 A.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29
A.4. DNS Naming Services and Service Discovery . . . . . . . . 28 A.4. DNS Naming Services and Service Discovery . . . . . . . . 30
A.5. IPv6 over Cellular Networks . . . . . . . . . . . . . . . 28 A.5. IPv6 over Cellular Networks . . . . . . . . . . . . . . . 30
A.5.1. Cellular V2X (C-V2X) Using 4G-LTE . . . . . . . . . . 28 A.5.1. Cellular V2X (C-V2X) Using 4G-LTE . . . . . . . . . . 30
A.5.2. Cellular V2X (C-V2X) Using 5G . . . . . . . . . . . . 29 A.5.2. Cellular V2X (C-V2X) Using 5G . . . . . . . . . . . . 31
Appendix B. Changes from draft-ietf-ipwave-vehicular- Appendix B. Changes from draft-ietf-ipwave-vehicular-
networking-05 . . . . . . . . . . . . . . . . . . . 29 networking-06 . . . . . . . . . . . . . . . . . . . 31
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 29 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 31
Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 29 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Vehicular networking studies have mainly focused on driving safety, Vehicular networking studies have mainly focused on driving safety,
driving efficiency, and entertainment in road networks. The Federal driving efficiency, and entertainment in road networks. The Federal
Communications Commission (FCC) in the US allocated wireless channels Communications Commission (FCC) in the US allocated wireless channels
for Dedicated Short-Range Communications (DSRC) [DSRC], service in for Dedicated Short-Range Communications (DSRC) [DSRC], service in
the Intelligent Transportation Systems (ITS) Radio Service in the the Intelligent Transportation Systems (ITS) Radio Service in the
5.850 - 5.925 GHz band (5.9 GHz band). DSRC-based wireless 5.850 - 5.925 GHz band (5.9 GHz band). DSRC-based wireless
communications can support vehicle-to-vehicle (V2V), vehicle-to- communications can support vehicle-to-vehicle (V2V), vehicle-to-
skipping to change at page 5, line 12 skipping to change at page 5, line 12
Positioning System (GPS)) is included in a vehicle with an OBU for Positioning System (GPS)) is included in a vehicle with an OBU for
efficient navigation. efficient navigation.
o Vehicle Detection Loop (or Loop Detector): An inductive device o Vehicle Detection Loop (or Loop Detector): An inductive device
used for detecting vehicles passing or arriving at a certain used for detecting vehicles passing or arriving at a certain
point, for instance approaching a traffic light or in motorway point, for instance approaching a traffic light or in motorway
traffic. The relatively crude nature of the loop's structure traffic. The relatively crude nature of the loop's structure
means that only metal masses above a certain size are capable of means that only metal masses above a certain size are capable of
triggering the detection. triggering the detection.
o Mobility Anchor (MA): A node that maintains IP addresses and
mobility information of vehicles in a road network to support the
address autoconfiguration and mobility management of them. It has
end-to-end connections with RSUs under its control. It maintains
a DAD table having the IP addresses of the vehicles moving within
the communication coverage of its RSUs.
o Vehicular Cloud: A cloud infrastructure for vehicular networks, o Vehicular Cloud: A cloud infrastructure for vehicular networks,
having compute nodes, storage nodes, and network nodes. having compute nodes, storage nodes, and network nodes.
o Traffic Control Center (TCC): A node that maintains road o Traffic Control Center (TCC): A node that maintains road
infrastructure information (e.g., RSUs, traffic signals, and loop infrastructure information (e.g., RSUs, traffic signals, and loop
detectors), vehicular traffic statistics (e.g., average vehicle detectors), vehicular traffic statistics (e.g., average vehicle
speed and vehicle inter-arrival time per road segment), and speed and vehicle inter-arrival time per road segment), and
vehicle information (e.g., a vehicle's identifier, position, vehicle information (e.g., a vehicle's identifier, position,
direction, speed, and trajectory as a navigation path). TCC is direction, speed, and trajectory as a navigation path). TCC is
included in a vehicular cloud for vehicular networks. included in a vehicular cloud for vehicular networks.
skipping to change at page 10, line 4 skipping to change at page 10, line 4
the corresponding IP address in multicast. DNS Name the corresponding IP address in multicast. DNS Name
Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming service Autoconfiguration (DNSNA) [ID-DNSNA] proposes a DNS naming service
for Internet-of-Things (IoT) devices in a large-scale network. for Internet-of-Things (IoT) devices in a large-scale network.
4.1.6. Service Discovery 4.1.6. Service Discovery
To discover instances of a demanded service in vehicular networks, To discover instances of a demanded service in vehicular networks,
DNS-based Service Discovery (DNS-SD) [RFC6763] with either DNSNA DNS-based Service Discovery (DNS-SD) [RFC6763] with either DNSNA
[ID-DNSNA] or mDNS [RFC6762] provides vehicles with service discovery [ID-DNSNA] or mDNS [RFC6762] provides vehicles with service discovery
by using standard DNS queries. Vehicular ND [ID-Vehicular-ND] by using standard DNS queries. Vehicular ND [ID-Vehicular-ND]
proposes an extension of IPv6 ND for the prefix and service proposes an extension of IPv6 ND for the prefix and service discovery
discovery. Note that a DNS query for service discovery is unicasted with new ND options [ID-VND-Discovery]. Note that a DNS query for
in DNSNA, but it is multicasted in both mDNS and Vehicular ND. service discovery is unicasted in DNSNA, but it is multicasted in
both mDNS and Vehicular ND.
4.1.7. Security and Privacy 4.1.7. Security and Privacy
For security and privacy, Fernandez et al. proposed a secure For security and privacy, Fernandez et al. proposed a secure
vehicular IPv6 communication scheme using Internet Key Exchange vehicular IPv6 communication scheme using Internet Key Exchange
version 2 (IKEv2) and Internet Protocol Security (IPsec) version 2 (IKEv2) and Internet Protocol Security (IPsec)
[Securing-VCOMM]. Moustafa et al. proposed a security scheme [Securing-VCOMM]. Moustafa et al. proposed a security scheme
providing authentication, authorization, and accounting (AAA) providing authentication, authorization, and accounting (AAA)
services in vehicular networks [VNET-AAA]. services in vehicular networks [VNET-AAA].
*-------------*
* * +-------+
* Vehicular Cloud *<------>| TCC |
* * +_______+
*-------------*
^ ^
| |
| |
v v
+--------+ Ethernet +--------+
| RSU1 |<----------->| RSU2 |
+________+ +________+
^ ^ ^
: : :
V2I : : V2I V2I :
v v v
+--------+ +--------+ +--------+
|Vehicle1|==> |Vehicle2|==> |Vehicle3|==>
| |<....>| |<....>| |
+________+ V2V +________+ V2V +________+
<----> Wired Link <....> Wireless Link ==> Moving Direction
Figure 1: A Vehicular Network Architecture for V2I and V2V Networking
4.2. General Problems 4.2. General Problems
This section describes a possible vehicular network architecture for This section describes a possible vehicular network architecture for
V2V, V2I, and V2X communications. Then it analyzes the limitations V2V, V2I, and V2X communications. Then it analyzes the limitations
of the current protocols for vehicular networking. of the current protocols for vehicular networking.
Traffic Control Center in Vehicular Cloud
*-----------------------------------------*
* *
* +----------------+ *
* | Mobility Anchor| *
* +----------------+ *
* ^ *
* | *
*--------------------v--------------------*
^ ^ ^
| | |
+------------------ | -------------|-------------+ +------------------+
| v v | | v |
| +--------+ Ethernet +--------+ | | +--------+ |
| | RSU1 |<----------->| RSU2 |<---------->| RSU3 | |
| +--------+ +--------+ | | +--------+ |
| ^ ^ ^ | | ^ |
| : : : | | : |
| V2I : : V2I V2I : | | V2I : |
| v 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
4.2.1. Vehicular Network Architecture 4.2.1. Vehicular Network Architecture
Figure 1 shows a possible architecture for V2I and V2V networking in Figure 1 shows a possible architecture for V2I and V2V networking in
a road network. It is assumed that RSUs as routers and vehicles with a road network. It is assumed that RSUs as routers and vehicles with
OBU have wireless media interfaces (e.g., IEEE 802.11-OCB, LTE Uu and OBU have wireless media interfaces (e.g., IEEE 802.11-OCB, LTE Uu and
Device-to-Device (D2D) (also known as PC5 [TS-23.285-3GPP]), Device-to-Device (D2D) (also known as PC5 [TS-23.285-3GPP]),
Bluetooth, and Light Fidelity (Li-Fi)) for V2I and V2V communication. Bluetooth, and Light Fidelity (Li-Fi)) for V2I and V2V communication.
Also, it is assumed that such the wireless media interfaces are Also, it is assumed that such the wireless media interfaces are
autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to
support both V2V and V2I networking. The two RSUs (RSU1 and RSU2) support both V2V and V2I networking. Three RSUs (RSU1, RSU2, and
are deployed in the road network and are connected to a Vehicular RSU3) are deployed in the road network and are connected to a
Cloud through the Internet. TCC is connected to the Vehicular Cloud Vehicular Cloud through the Internet. A Traffic Control Center (TCC)
and the two vehicles (Vehicle1 and Vehicle2) are wirelessly connected is connected to the Vehicular Cloud for the management of RSUs and
to RSU1, and the last vehicle (Vehicle3) is wirelessly connected to vehicles in the road network. A Mobility Anchor (MA) is located in
RSU2. Vehicle1 can communicate with Vehicle2 via V2V communication, the TCC as its key component for the mobility management of vehicles.
and Vehicle2 can communicate with Vehicle3 via V2V communication. Two vehicles (Vehicle1 and Vehicle2) are wirelessly connected to
Vehicle1 can communicate with Vehicle3 via RSU1 and RSU2 employing RSU1, and one vehicle (Vehicle3) is wirelessly connected to RSU2.
V2I (i.e., V2I2V) communication. The wireless networks of RSU1 and RSU2 belong to a multi-link subnet
(denoted as Subnet1) with the same network prefix. Thus, these three
vehicles are within the same subnet. On the other hand, another
vehicle (Vehicle4) is wireless connected to RSU4, belonging to
another subnet (denoted as Subnet2). That is, the first three
vehicles (i.e., Vehicle1, Vehicle2, and Vehicle3) and the last
vehicle (i.e., Vehicle4) are located in the two different subnets.
Vehicle1 can communicate with Vehicle2 via V2V communication, and
Vehicle2 can communicate with Vehicle3 via V2V communication because
they are within the same subnet along their IPv6 addresses, which are
based on the same prefix. On the other hand, Vehicle3 can
communicate with Vehicle4 via RSU2 and RSU3 employing V2I (i.e.,
V2I2V) communication because they are within the two different
subnets along with their IPv6 addresses, which are based on the two
different prefixes.
In vehicular networks, unidirectional links exist and must be In vehicular networks, unidirectional links exist and must be
considered for wireless communications. Also, in the vehicular considered for wireless communications. Also, in the vehicular
networks, control plane must be separated from data plane for networks, control plane must be separated from data plane for
efficient mobility management and data forwarding using Software- efficient mobility management and data forwarding using Software-
Defined Networking (SDN) [SDN-DMM]. ID/Pseudonym change for privacy Defined Networking (SDN) [SDN-DMM]. ID/Pseudonym change for privacy
requires a lightweight DAD. IP tunneling over the wireless link requires a lightweight DAD. IP tunneling over the wireless link
should be avoided for performance efficiency. The mobility should be avoided for performance efficiency. The mobility
information of a mobile (e.g., vehicle-mounted) device through a GPS information of a mobile (e.g., vehicle-mounted) device through a GPS
receiver in its vehicle, such as trajectory, position, speed, and receiver in its vehicle, such as trajectory, position, speed, and
skipping to change at page 13, line 13 skipping to change at page 14, line 10
network and an RSU's fixed network via V2I communication. network and an RSU's fixed network via V2I communication.
As shown in Figure 2, the vehicle's moving network and the RSU's As shown in Figure 2, the vehicle's moving network and the RSU's
fixed network are self-contained networks having multiple subnets and fixed network are self-contained networks having multiple subnets and
having an edge router for the communication with another vehicle or having an edge router for the communication with another vehicle or
RSU. The method of prefix assignment for each subnet inside the RSU. The method of prefix assignment for each subnet inside the
vehicle's mobile network and the RSU's fixed network is out of scope vehicle's mobile network and the RSU's fixed network is out of scope
for this document. Internetworking between two internal networks via for this document. Internetworking between two internal networks via
V2I communication requires an exchange of network prefix and other V2I communication requires an exchange of network prefix and other
parameters through a prefix discovery mechanism, such as ND-based parameters through a prefix discovery mechanism, such as ND-based
prefix discovery [ID-Vehicular-ND]. For the ND-based prefix prefix discovery [ID-VND-Discovery]. For the ND-based prefix
discovery, network prefixs and parameters should be registered into a discovery, network prefixs and parameters should be registered into a
vehicle's router and an RSU router with an external network interface vehicle's router and an RSU router with an external network interface
in advance. in advance.
The network parameter discovery collects networking information for The network parameter discovery collects networking information for
an IP communication between a vehicle and an RSU or between two an IP communication between a vehicle and an RSU or between two
neighboring vehicles, such as link layer, MAC layer, and IP layer neighboring vehicles, such as link layer, MAC layer, and IP layer
information. The link layer information includes wireless link layer information. The link layer information includes wireless link layer
parameters, such as wireless media (e.g., IEEE 802.11-OCB, LTE Uu and parameters, such as wireless media (e.g., IEEE 802.11-OCB, LTE Uu and
D2D, Bluetooth, and LiFi) and a transmission power level. Note that D2D, Bluetooth, and LiFi) and a transmission power level. Note that
skipping to change at page 13, line 42 skipping to change at page 14, line 39
have been performed, packets can be transmitted between the vehicle's have been performed, packets can be transmitted between the vehicle's
moving network and the RSU's fixed network. DNS services should be moving network and the RSU's fixed network. DNS services should be
supported to enable name resolution for hosts or servers residing supported to enable name resolution for hosts or servers residing
either in the vehicle's moving network or the RSU's fixed network. either in the vehicle's moving network or the RSU's fixed network.
It is assumed that the DNS names of in-vehicle devices and their It is assumed that the DNS names of in-vehicle devices and their
service names are registered into a DNS server (i.e., recursive DNS service names are registered into a DNS server (i.e., recursive DNS
server called RDNSS) in a vehicle or an RSU, as shown in Figure 2. server called RDNSS) in a vehicle or an RSU, as shown in Figure 2.
For service discovery, those DNS names and service names can be For service discovery, those DNS names and service names can be
advertised to neighboring vehicles through either DNS-based service advertised to neighboring vehicles through either DNS-based service
discovery mechanisms [RFC6762][RFC6763][ID-DNSNA] and ND-based discovery mechanisms [RFC6762][RFC6763][ID-DNSNA] and ND-based
service discovery [ID-Vehicular-ND]. For the ND-based service service discovery [ID-Vehicular-ND][ID-VND-Discovery]. For the ND-
discovery, service names should be registered into a vehicle's router based service discovery, service names should be registered into a
and an RSU router with an external network interface in advance. vehicle's router and an RSU router with an external network interface
Refer to Section 4.1.5 and Section 4.1.6 for detailed information. in advance. Refer to Section 4.1.5 and Section 4.1.6 for detailed
For these DNS services, an RDNSS within each internal network of a information. For these DNS services, an RDNSS within each internal
vehicle or RSU can be used for the hosts or servers. network of a vehicle or RSU can be used for the hosts or servers.
Figure 2 shows internetworking between the vehicle's moving network Figure 2 shows internetworking between the vehicle's moving network
and the RSU's fixed network. There exists an internal network and the RSU's fixed network. There exists an internal network
(Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server
(RDNSS1), the two hosts (Host1 and Host2), and the two routers (RDNSS1), the two hosts (Host1 and Host2), and the two routers
(Router1 and Router2). There exists another internal network (Fixed (Router1 and Router2). There exists another internal network (Fixed
Network1) inside RSU1. RSU1 has the DNS Server (RDNSS2), one host Network1) inside RSU1. RSU1 has the DNS Server (RDNSS2), one host
(Host3), the two routers (Router3 and Router4), and the collection of (Host3), the two routers (Router3 and Router4), 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.
skipping to change at page 16, line 31 skipping to change at page 17, line 31
Advertisement (NA) interval should be adjusted for high-speed Advertisement (NA) interval should be adjusted for high-speed
vehicles and vehicle density. As vehicles move faster, the NA vehicles and vehicle density. As vehicles move faster, the NA
interval should decrease for the NA messages to reach the neighboring interval should decrease for the NA messages to reach the neighboring
vehicles promptly. Also, as vehicle density is higher, the NA vehicles promptly. Also, as vehicle density is higher, the NA
interval should increase for the NA messages to reduce collision interval should increase for the NA messages to reduce collision
probability with other NA messages. probability with other NA messages.
5.1.1. Link Model 5.1.1. Link Model
IPv6 protocols work under certain assumptions for the link model that IPv6 protocols work under certain assumptions for the link model that
do not necessarily hold in WAVE [IPv6-WAVE]. For instance, some IPv6 do not necessarily hold in a vehicular wireless link [VIP-WAVE]. For
protocols assume symmetry in the connectivity among neighboring instance, some IPv6 protocols assume symmetry in the connectivity
interfaces. However, interference and different levels of among neighboring interfaces. However, interference and different
transmission power may cause unidirectional links to appear in a WAVE levels of transmission power may cause unidirectional links to appear
link model. in vehicular wireless links. As a result, a new vehicular link model
is required for the vehicular wireless link.
There is a relationship between a link and prefix, besides the There is a relationship between a link and prefix, besides the
different scopes that are expected from the link-local and global different scopes that are expected from the link-local and global
types of IPv6 addresses. In an IPv6 link, it is assumed that all types of IPv6 addresses. In an IPv6 link, it is assumed that all
interfaces which are configured with the same subnet prefix and with interfaces which are configured with the same subnet prefix and with
on-link bit set can communicate with each other on an IP link or on-link bit set can communicate with each other on an IP link or
extended IP links via ND proxy. Note that a subnet prefix can be extended IP links via ND proxy. Note that a subnet prefix can be
used by spanning multiple links as a multi-link subnet [RFC6775]. used by spanning multiple links as a multi-link subnet [RFC6775].
Also, note that IPv6 Stateless Address Autoconfiguration can be Also, note that IPv6 Stateless Address Autoconfiguration can be
performed in the multiple links where each of them is not assigned performed in the multiple links where each of them is not assigned
with a unique subnet prefix, that is, all of them are configured with with a unique subnet prefix, that is, all of them are configured with
the same subnet prefix [RFC4861][RFC4862]. A WAVE link model needs the same subnet prefix [RFC4861][RFC4862]. A vehicular link model
to consider a multi-hop VANET over a multi-link subnet. Such a VANET needs to consider a multi-hop VANET over a multi-link subnet. Such a
is usually a multi-link subnet consisting of multiple vehicles VANET is usually a multi-link subnet consisting of multiple vehicles
interconnected by wireless communication range. Such a subnet has a interconnected by wireless communication range. Such a subnet has a
highly dynamic topology over time due to node mobility. highly dynamic topology over time due to node mobility.
Thus, IPv6 ND should be extended to support the concept of an IPv6 Thus, IPv6 ND should be extended into a Vehicular Neighbor Discovey
link corresponding to an IPv6 prefix even in a multi-link subnet (VND) [ID-Vehicular-ND] to support the concept of an IPv6 link
corresponding to an IPv6 prefix even in a multi-link subnet
consisting of multiple vehicles and RSUs that are interconnected with consisting of multiple vehicles and RSUs that are interconnected with
wireless communication range in vehicular networks. wireless communication range in IP-based vehicular networks.
5.1.2. MAC Address Pseudonym 5.1.2. MAC Address Pseudonym
In the ETSI standards, for the sake of security and privacy, an ITS In the ETSI standards, for the sake of security and privacy, an ITS
station (e.g., vehicle) can use pseudonyms for its network interface station (e.g., vehicle) can use pseudonyms for its network interface
identities (e.g., MAC address) and the corresponding IPv6 addresses identities (e.g., MAC address) and the corresponding IPv6 addresses
[Identity-Management]. Whenever the network interface identifier [Identity-Management]. Whenever the network interface identifier
changes, the IPv6 address based on the network interface identifier changes, the IPv6 address based on the network interface identifier
should be updated. For the continuity of an end-to-end (E2E) should be updated. For the continuity of an end-to-end (E2E)
transport-layer (e.g., TCP, UDP, and SCTP) session, the new IP transport-layer (e.g., TCP, UDP, and SCTP) session, with a mobility
addresses of the transport-layer session should be notified to both management scheme (e.g., MIPv6 and PMIPv6), the new IP address for
the end points and the packets of the session should be forwarded to the transport-layer session should be notified to an appropriate end
their destinations with the changed network interface identifier and point, and the packets of the session should be forwarded to their
IPv6 address. destinations with the changed network interface identifier and IPv6
address.
5.1.3. Prefix Dissemination/Exchange 5.1.3. Prefix Dissemination/Exchange
A vehicle and an RSU can have their internal network, as shown in A vehicle and an RSU can have their internal network, as shown in
Figure 2 and Figure 3. In this case, nodes in within the internal Figure 2 and Figure 3. In this case, nodes in within the internal
networks of two vehicular nodes (e.g., vehicle and RSU) want to networks of two vehicular nodes (e.g., vehicle and RSU) want to
communicate with each other. For this communication on the wireless communicate with each other. For this communication on the wireless
link, the network prefix dissemination or exchange is required. It link, the network prefix dissemination or exchange is required. It
is assumed that a vehicular node has an external network interface is assumed that a vehicular node has an external network interface
and its internal network. The standard IPv6 ND needs to be extended and its internal network. The legacy IPv6 ND [RFC4861] needs to be
for the communication between the internal-network vehicular nodes by extended to a vehicular ND (VND) [ID-Vehicular-ND] for the
communication between the internal-network nodes (e.g., an in-vehicle
device in a vehicle and a server in an RSU) of vehicular nodes by
letting each of them know the other side's prefix with a new ND letting each of them know the other side's prefix with a new ND
option [ID-Vehicular-ND]. Thus, this ND extension for routing option [ID-VND-Discovery]. Thus, this ND extension for routing
functionality can reduce control traffic for routing in vehicular functionality can reduce control traffic for routing in vehicular
networks. networks without an additional vehicular ad hoc routing protocol
[VANET-Geo-Routing].
5.1.4. Routing 5.1.4. Routing
For Neighbor Discovery in vehicular networks (called vehicular ND), For multihop V2V communications in a multi-link subnet (as a
Ad Hoc routing is required for either unicast or multicast in the connected VANET), a vehicular ad hoc routing protocol (e.g.,
links in a connected VANET with the same IPv6 prefix [GeoSAC]. Also, geographic routing) may be required to support both unicast and
a rapid DAD should be supported to prevent or reduce IPv6 address multicast in the links of the subnet with the same IPv6 prefix
conflicts in a multi-link subnet for both V2V and V2I by using a DAD [VANET-Geo-Routing]. Instead of the vehicular ad hoc routing
optimization [RFC6775]. protocol, Vehicular ND along with a prefix discovery option can be
used to let vehicles exchange their prefixes in a multihop fashion
[ID-Vehicular-ND][ID-VND-Discovery]. With the exchanged prefixes,
they can compute their routing table (or IPv6 ND's neighbor cache)
for the multi-link subnet with a distance-vector algorithm
[Intro-to-Algorithms]. Also, an efficient, rapid DAD should be
supported to prevent or reduce IPv6 address conflicts in the multi-
link subnet by using a DAD optimization [ID-Vehicular-ND][RFC6775] or
an IPv6 geographic-routing-based address autoconfiguration [GeoSAC].
5.2. Mobility Management 5.2. Mobility Management
The seamless connectivity and timely data exchange between two end The seamless connectivity and timely data exchange between two end
points requires an efficient mobility management including location points requires an efficient mobility management including location
management and handover. Most of vehicles are equipped with a GPS management and handover. Most of vehicles are equipped with a GPS
receiver as part of a dedicated navigation system or a corresponding receiver as part of a dedicated navigation system or a corresponding
smartphone App. In the case where the provided location information smartphone App. In the case where the provided location information
is precise enough, well-known temporary degradations in precision may is precise enough, well-known temporary degradations in precision may
occur due to system configuration or the adverse local environment. occur due to system configuration or the adverse local environment.
This precision is improved thanks to assistance by the RSUs or a This precision is improved thanks to assistance by the RSUs or a
cellular system with this navigation system. With this GPS cellular system with this navigation system. With this GPS
navigator, an efficient mobility management is possible by vehicles navigator, an efficient mobility management is possible by vehicles
periodically reporting their current position and trajectory (i.e., periodically reporting their current position and trajectory (i.e.,
navigation path) to TCC. TCC can predict the future positions of the navigation path) to RSUs and a Mobility Anchor (MA) in TCC. The RSUs
vehicles with their mobility information (i.e., the current position, and MA can predict the future positions of the vehicles with their
speed, direction, and trajectory) for location management. mobility information (i.e., the current position, speed, direction,
and trajectory) for the efficient mobility management (e.g.,
proactive handover). For a better proactive handover, link-layer
parameters, such as the signal strength of a link-layer frame (e.g.,
Received Channel Power Indicator (RCPI) [VIP-WAVE]), can be used to
determine the moment of a handover between RSUs along with mobility
information [ID-Vehicular-ND].
With the prediction of the vehicle mobility, TCC can support RSUs to With the prediction of the vehicle mobility, MA can support RSUs to
perform DAD, data packet routing, horizontal handover (i.e., handover perform DAD, data packet routing, horizontal handover (i.e., handover
in wireless links using a homogeneous radio technology), and vertical in wireless links using a homogeneous radio technology), and vertical
handover (i.e., handover in wireless links using heterogeneous radio handover (i.e., handover in wireless links using heterogeneous radio
technologies) in a proactive manner. When it is assigned a new IPv6 technologies) in a proactive manner. Even though a vehicle moves
address belonging to a different subnet, a vehicle can skip the DAD into the wireless link under another RSU belonging to a different
operation, reducing IPv6 control traffic overhead. RSUs can subnet, the RSU can proactively perform the DAD for the sake of the
efficiently forward data packets from the wired network to a moving vehicle, reducing IPv6 control traffic overhead in the wireless link
destination vehicle along its trajectory. RSUs can smoothly perform [ID-Vehicular-ND].
handover for the sake of a moving vehicle along its trajectory.
Therefore, with a proactive handover and a multihop DAD in vehicular
networks [ID-Vehicular-ND], RSUs can efficiently forward data packets
from the wired network (or the wireless network) to a moving
destination vehicle along its trajectory along with the MA. Thus, a
moving vehicle can communicate with its corresponding vehicle in the
vehicular network or a host/server in the Internet along its
trajectory.
5.3. Security and Privacy 5.3. Security and Privacy
Security and privacy are paramount in the V2I, V2V, and V2X Security and privacy are paramount in the V2I, V2V, and V2X
networking in vehicular networks. Only authorized vehicles should be networking in vehicular networks. Only authorized vehicles should be
allowed to use vehicular networking. Also, in-vehicle devices and allowed to use vehicular networking. Also, in-vehicle devices and
mobile devices in a vehicle need to communicate with other in-vehicle mobile devices in a vehicle need to communicate with other in-vehicle
devices and mobile devices in another vehicle, and other servers in devices and mobile devices in another vehicle, and other servers in
an RSU in a secure way. an RSU in a secure way.
skipping to change at page 21, line 34 skipping to change at page 23, line 17
Mobile Users", IEEE International Conference on Mobile Users", IEEE International Conference on
Communications, June 2015. Communications, June 2015.
[ID-DNSNA] [ID-DNSNA]
Jeong, J., Ed., Lee, S., and J. Park, "DNS Name Jeong, J., Ed., Lee, S., and J. Park, "DNS Name
Autoconfiguration for Internet of Things Devices", draft- Autoconfiguration for Internet of Things Devices", draft-
jeong-ipwave-iot-dns-autoconf-04 (work in progress), jeong-ipwave-iot-dns-autoconf-04 (work in progress),
October 2018. October 2018.
[ID-Vehicular-ND] [ID-Vehicular-ND]
Xiang, Zhong., Jeong, J., Ed., and Y. Shen, "IPv6 Neighbor
Discovery for IP-Based Vehicular Networks", draft-xiang-
ipwave-vehicular-neighbor-discovery-00 (work in progress),
November 2018.
[ID-VND-Discovery]
Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and J. Lee, Jeong, J., Ed., Shen, Y., Jo, Y., Jeong, J., and J. Lee,
"IPv6 Neighbor Discovery for Prefix and Service Discovery "IPv6 Neighbor Discovery for Prefix and Service Discovery
in Vehicular Networks", draft-jeong-ipwave-vehicular- in Vehicular Networks", draft-jeong-ipwave-vehicular-
neighbor-discovery-04 (work in progress), October 2018. neighbor-discovery-04 (work in progress), October 2018.
[Identity-Management] [Identity-Management]
Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer
Identities Management in ITS Stations", The 10th Identities Management in ITS Stations", The 10th
International Conference on ITS Telecommunications, International Conference on ITS Telecommunications,
November 2010. November 2010.
skipping to change at page 22, line 11 skipping to change at page 23, line 45
IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Access Control (MAC) and Physical Layer (PHY)
Specifications", IEEE Std 802.11-2016, December 2016. Specifications", IEEE Std 802.11-2016, December 2016.
[IEEE-802.11p] [IEEE-802.11p]
IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Access Control (MAC) and Physical Layer (PHY)
Specifications - Amendment 6: Wireless Access in Vehicular Specifications - Amendment 6: Wireless Access in Vehicular
Environments", IEEE Std 802.11p-2010, June 2010. Environments", IEEE Std 802.11p-2010, June 2010.
[Intro-to-Algorithms]
H. Cormen, T., E. Leiserson, C., L. Rivest, R., and C.
Stein, "Introduction to Algorithms, 3rd ed.", The
MIT Press, July 2009.
[IP-Passing-Protocol] [IP-Passing-Protocol]
Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol for Chen, Y., Hsu, C., and W. Yi, "An IP Passing Protocol for
Vehicular Ad Hoc Networks with Network Fragmentation", Vehicular Ad Hoc Networks with Network Fragmentation",
Elsevier Computers & Mathematics with Applications, Elsevier Computers & Mathematics with Applications,
January 2012. January 2012.
[IPv6-over-802.11-OCB] [IPv6-over-802.11-OCB]
Petrescu, A., Benamar, N., Haerri, J., Lee, J., and T. Petrescu, A., Benamar, N., Haerri, J., Lee, J., and T.
Ernst, "Transmission of IPv6 Packets over IEEE 802.11 Ernst, "Transmission of IPv6 Packets over IEEE 802.11
Networks operating in mode Outside the Context of a Basic Networks operating in mode Outside the Context of a Basic
Service Set (IPv6-over-80211-OCB)", draft-ietf-ipwave- Service Set (IPv6-over-80211-OCB)", draft-ietf-ipwave-
ipv6-over-80211ocb-25 (work in progress), June 2018. ipv6-over-80211ocb-30 (work in progress), September 2018.
[IPv6-WAVE] [IPv6-WAVE]
Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6 Baccelli, E., Clausen, T., and R. Wakikawa, "IPv6
Operation for WAVE - Wireless Access in Vehicular Operation for WAVE - Wireless Access in Vehicular
Environments", IEEE Vehicular Networking Conference, Environments", IEEE Vehicular Networking Conference,
December 2010. December 2010.
[ISO-ITS-IPv6] [ISO-ITS-IPv6]
ISO/TC 204, "Intelligent Transport Systems - ISO/TC 204, "Intelligent Transport Systems -
Communications Access for Land Mobiles (CALM) - IPv6 Communications Access for Land Mobiles (CALM) - IPv6
skipping to change at page 25, line 40 skipping to change at page 27, line 29
[VANET-Geo-Routing] [VANET-Geo-Routing]
Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Goleva, Tsukada, M., Jemaa, I., Menouar, H., Zhang, W., Goleva,
M., and T. Ernst, "Experimental Evaluation for IPv6 over M., and T. Ernst, "Experimental Evaluation for IPv6 over
VANET Geographic Routing", IEEE International Wireless VANET Geographic Routing", IEEE International Wireless
Communications and Mobile Computing Conference, June 2010. Communications and Mobile Computing Conference, June 2010.
[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
Systems, March 2013. Systems, vol. 14, no. 1, March 2013.
[VMaSC-LTE] [VMaSC-LTE]
Ucar, S., Ergen, S., and O. Ozkasap, "Multihop-Cluster- Ucar, S., Ergen, S., and O. Ozkasap, "Multihop-Cluster-
Based IEEE 802.11p and LTE Hybrid Architecture for VANET Based IEEE 802.11p and LTE Hybrid Architecture for VANET
Safety Message Dissemination", IEEE Transactions on Safety Message Dissemination", IEEE Transactions on
Vehicular Technology, April 2016. Vehicular Technology, April 2016.
[VNET-AAA] [VNET-AAA]
Moustafa, H., Bourdon, G., and Y. Gourhant, "Providing Moustafa, H., Bourdon, G., and Y. Gourhant, "Providing
Authentication and Access Control in Vehicular Network Authentication and Access Control in Vehicular Network
skipping to change at page 28, line 20 skipping to change at page 30, line 20
recursive DNS server (RDNSS) within an internal network can perform recursive DNS server (RDNSS) within an internal network can perform
such DNS name resolution for the sake of other vehicular nodes. such DNS name resolution for the sake of other vehicular nodes.
A service discovery service is required for an application in a A service discovery service is required for an application in a
vehicular node to search for another application or server in another vehicular node to search for another application or server in another
vehicular node, which resides in either the same internal network or vehicular node, which resides in either the same internal network or
the other internal network. In V2I or V2V networking, as shown in the other internal network. In V2I or V2V networking, as shown in
Figure 2 and Figure 3, such a service discovery service can be Figure 2 and Figure 3, such a service discovery service can be
provided by either DNS-based Service Discovery (DNS-SD) [RFC6763] provided by either DNS-based Service Discovery (DNS-SD) [RFC6763]
with mDNS [RFC6762] or the vehicular ND with a new option for service with mDNS [RFC6762] or the vehicular ND with a new option for service
discovery [ID-Vehicular-ND]. discovery [ID-Vehicular-ND][ID-VND-Discovery].
A.5. IPv6 over Cellular Networks A.5. IPv6 over Cellular Networks
Recently, 3GPP has announced a set of new technical specifications, Recently, 3GPP has announced a set of new technical specifications,
such as Release 14 (3GPP-R14), which proposes an architecture such as Release 14 (3GPP-R14), which proposes an architecture
enhancements for V2X services using the modified sidelink interface enhancements for V2X services using the modified sidelink interface
that originally is designed for the LTE-D2D communications. 3GPP-R14 that originally is designed for the LTE-D2D communications. 3GPP-R14
specifies that the V2X services only support IPv6 implementation. specifies that the V2X services only support IPv6 implementation.
3GPP is also investigating and discussing the evolved V2X services in 3GPP is also investigating and discussing the evolved V2X services in
the next generation cellular networks, i.e., 5G new radio (5G-NR), the next generation cellular networks, i.e., 5G new radio (5G-NR),
skipping to change at page 29, line 16 skipping to change at page 31, line 16
The emerging services, functions, and applications, which are The emerging services, functions, and applications, which are
developped in automotive industry, demand reliable and efficient developped in automotive industry, demand reliable and efficient
communication infrastructure for road networks. Correspondingly, the communication infrastructure for road networks. Correspondingly, the
support of enhanced V2X (eV2X)-based services by future converged and support of enhanced V2X (eV2X)-based services by future converged and
interoperable 5G systems is required. The 3GPP Technical Report interoperable 5G systems is required. The 3GPP Technical Report
[TR-22.886-3GPP] is studying new use cases and the corresponding [TR-22.886-3GPP] is studying new use cases and the corresponding
service requirements for V2X (including V2V and V2I) using 5G in both service requirements for V2X (including V2V and V2I) using 5G in both
infrastructure mode and the sidelink variations in the future. infrastructure mode and the sidelink variations in the future.
Appendix B. Changes from draft-ietf-ipwave-vehicular-networking-05 Appendix B. Changes from draft-ietf-ipwave-vehicular-networking-06
The following changes are made from draft-ietf-ipwave-vehicular- The following changes are made from draft-ietf-ipwave-vehicular-
networking-05: networking-06:
o In Figure 2 and Figure 3, the vehicle networks and RSU network are o In Figure 1, a vehicular network architecture is modified to show
updated. a vehicular link model in a multi-link subnet with vehicular
wireless links.
o In Section 5.1, a Vehicular Neighbor Discovery (VND)
[ID-Vehicular-ND] is introduced along with a vehicular link model
in a multi-link subnet. In such a subnet, the description of MAC
Address Pseudonym, Prefix Dissemination/Exchange, and Routing is
clarified.
o In Section 5.2, a proactive handover is introduced for an
efficient mobility management with the cooperation among vehicles,
RSUs, and MA along with link-layer parameters, such as Received
Channel Power Indicator (RCPI).
Appendix C. Acknowledgments Appendix C. Acknowledgments
This work was supported by Basic Science Research Program through the This work was supported by Basic Science Research Program through the
National Research Foundation of Korea (NRF) funded by the Ministry of National Research Foundation of Korea (NRF) funded by the Ministry of
Education (2017R1D1A1B03035885). Education (2017R1D1A1B03035885).
This work was supported in part by Global Research Laboratory Program This work was supported in part by Global Research Laboratory Program
through the NRF funded by the Ministry of Science and ICT (MSIT) through the NRF funded by the Ministry of Science and ICT (MSIT)
(NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT
skipping to change at page 30, line 12 skipping to change at page 32, line 27
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
Department of Electrical Engineering NIC Chile Research Labs
Universidad de Chile Universidad de Chile
Av. Tupper 2007, Of. 504 Av. Blanco Encalada 1975
Santiago, 8370451 Santiago
Chile Chile
Phone: +56 2 29784093 Phone: +56 2 29784093
EMail: scespede@niclabs.cl EMail: scespede@niclabs.cl
Jerome Haerri Jerome Haerri
Communication Systems Department Communication Systems Department
EURECOM EURECOM
Sophia-Antipolis Sophia-Antipolis
France France
 End of changes. 35 change blocks. 
120 lines changed or deleted 200 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/