draft-ietf-ipwave-vehicular-networking-21.txt   draft-ietf-ipwave-vehicular-networking-22.txt 
IPWAVE Working Group J. Jeong, Ed. IPWAVE Working Group J. Jeong, Ed.
Internet-Draft Sungkyunkwan University Internet-Draft Sungkyunkwan University
Intended status: Informational 30 August 2021 Intended status: Informational 2 September 2021
Expires: 3 March 2022 Expires: 6 March 2022
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-21 draft-ietf-ipwave-vehicular-networking-22
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 3 March 2022. This Internet-Draft will expire on 6 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 33 skipping to change at page 2, line 33
4.1. Vehicular Network Architecture . . . . . . . . . . . . . 14 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 14
4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 15 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 15
4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 18 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 18
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 22 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 23 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 23
5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 25 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 25
5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 27 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 27
5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 27 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 28 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6.1. Security Threats in Neighbor Discovery . . . . . . . . . 31 6.1. Security Threats in Neighbor Discovery . . . . . . . . . 32
6.2. Security Threats in Mobility Management . . . . . . . . . 33 6.2. Security Threats in Mobility Management . . . . . . . . . 33
6.3. Other Threats . . . . . . . . . . . . . . . . . . . . . . 33 6.3. Other Threats . . . . . . . . . . . . . . . . . . . . . . 33
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. Normative References . . . . . . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . 35
8.2. Informative References . . . . . . . . . . . . . . . . . 39 8.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Support of Multiple Radio Technologies for V2V . . . 44 Appendix A. Support of Multiple Radio Technologies for V2V . . . 44
Appendix B. Support of Multihop V2X Networking . . . . . . . . . 45 Appendix B. Support of Multihop V2X Networking . . . . . . . . . 45
Appendix C. Support of Mobility Management for V2I . . . . . . . 45 Appendix C. Support of Mobility Management for V2I . . . . . . . 46
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 46 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 47
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 47 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49
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 4, line 51 skipping to change at page 4, line 51
* Edge Network (EN): It is an access network that has an IP-RSU for * Edge Network (EN): It is an access network that has an IP-RSU for
wireless communication with other vehicles having an IP-OBU and wireless communication with other vehicles having an IP-OBU and
wired communication with other network devices (e.g., routers, IP- wired communication with other network devices (e.g., routers, IP-
RSUs, ECDs, servers, and MA). It may have a Global Positioning RSUs, ECDs, servers, and MA). It may have a Global Positioning
System (GPS) radio receiver for its position recognition and the System (GPS) radio receiver for its position recognition and the
localization service for the sake of vehicles. localization service for the sake of vehicles.
* IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a * IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a
computer situated in a vehicle (e.g., car, bicycle, autobike, computer situated in a vehicle (e.g., car, bicycle, autobike,
motor cycle, and a similar one) and a device (e.g., smartphone and motor cycle, and a similar one) and a device (e.g., smartphone and
IoT device). It has at least one IP interface that runs in IEEE Internet-of-Things (IoT) device). It has at least one IP
802.11-OCB and has an "OBU" transceiver. Also, it may have an IP interface that runs in IEEE 802.11-OCB and has an "OBU"
interface that runs in Cellular V2X (C-V2X) [TS-23.285-3GPP] transceiver. Also, it may have an IP interface that runs in
Cellular V2X (C-V2X) [TS-23.285-3GPP]
[TR-22.886-3GPP][TS-23.287-3GPP]. It can play a role of a router [TR-22.886-3GPP][TS-23.287-3GPP]. It can play a role of a router
connecting multiple computers (or in-vehicle devices) inside a connecting multiple computers (or in-vehicle devices) inside a
vehicle. See the definition of the term "OBU" in [RFC8691]. vehicle. See the definition of the term "OBU" in [RFC8691].
* IP-RSU: "IP Roadside Unit": An IP-RSU is situated along the road. * IP-RSU: "IP Roadside Unit": An IP-RSU is situated along the road.
It has at least two distinct IP-enabled interfaces. The wireless It has at least two distinct IP-enabled interfaces. The wireless
PHY/MAC layer of at least one of its IP-enabled interfaces is PHY/MAC layer of at least one of its IP-enabled interfaces is
configured to operate in 802.11-OCB mode. An IP-RSU communicates configured to operate in 802.11-OCB mode. An IP-RSU communicates
with the IP-OBU over an 802.11 wireless link operating in OCB with the IP-OBU over an 802.11 wireless link operating in OCB
mode. Also, it may have an IP interface that runs in C-V2X along mode. Also, it may have an IP interface that runs in C-V2X along
skipping to change at page 28, line 8 skipping to change at page 27, line 52
A routing protocol for a VANET may cause redundant wireless frames in A routing protocol for a VANET may cause redundant wireless frames in
the air to check the neighborhood of each vehicle and compute the the air to check the neighborhood of each vehicle and compute the
routing information in a VANET with a dynamic network topology routing information in a VANET with a dynamic network topology
because the IPv6 ND is used to check the neighborhood of each because the IPv6 ND is used to check the neighborhood of each
vehicle. Thus, the vehicular routing needs to take advantage of the vehicle. Thus, the vehicular routing needs to take advantage of the
IPv6 ND to minimize its control overhead. IPv6 ND to minimize its control overhead.
RPL [RFC6550] defines a routing protocol for low-power and lossy RPL [RFC6550] defines a routing protocol for low-power and lossy
networks, which constructs and maintains DODAGs optimized by an networks, which constructs and maintains DODAGs optimized by an
Objective Function (OF). A defined OF provides route selection and Objective Function (OF). A defined OF provides route selection and
optimization within a RPL topology. A node in a DODAG uses DODAG optimization within an RPL topology. A node in a DODAG uses DODAG
Information Objects (DIOs) messages to discover and maintain the Information Objects (DIOs) messages to discover and maintain the
upward routes toward the root node. upward routes toward the root node. Refer to Appendix B for the
detailed description of RPL for multihop V2X networking.
An address registration extension for 6LoWPAN (IPv6 over Low-Power An address registration extension for 6LoWPAN (IPv6 over Low-Power
Wireless Personal Area Network) in [RFC8505] can support light-weight Wireless Personal Area Network) in [RFC8505] can support light-weight
mobility for nodes moving through different parents. Mainly it mobility for nodes moving through different parents. Mainly it
updates the Address Registration Option (ARO) of ND defined in updates the Address Registration Option (ARO) of ND defined in
[RFC6775] to include a status field that can indicate the movement of [RFC6775] to include a status field that can indicate the movement of
a node and optionally a Transaction ID (TID) field, i.e., a sequence a node and optionally a Transaction ID (TID) field, i.e., a sequence
number that can be used to determine the most recent location of a number that can be used to determine the most recent location of a
node. node.
RPL can use the information provided by the extended ARO defined in RPL can use the information provided by the extended ARO defined in
[RFC8505] to deal with a certain level of node mobility. When a leaf [RFC8505] to deal with a certain level of node mobility. When a leaf
node moves to the coverage of another parent node, it should de- node moves to the coverage of another parent node, it should de-
register its addresses to the previous parent node and register register its addresses to the previous parent node and register
itself with a new parent node along with an incremented TID. itself with a new parent node along with an incremented TID.
Although RPL can be used in IPv6-based vehicular networks, it is RPL can be used in IPv6-based vehicular networks, but it is primarily
primarily designed for lossy networks, which puts energy efficiency designed for lossy networks, which puts energy efficiency first. For
first. In addition, the topology it considers may not quickly scale using it in IPv6-based vehicular networks, there have not been actual
up and down for IPv6-based vehicular networks, since the mobility of experiences and practical implementations for vehicular networks,
vehicles is much more diverse with a high speed, so it can frequently though it was tested in IoT low-power and lossy networks (LLN)
alter a tree-like topology formed by RPL, which may cause network scenarios.
fragmentation and merging with more control traffic.
Moreover, due to bandwidth and energy constraints, RPL does not Moreover, due to bandwidth and energy constraints, RPL does not
suggest to use a proactive mechanism (e.g., keepalive) to maintain suggest to use a proactive mechanism (e.g., keepalive) to maintain
accurate routing adjacencies such as Bidirectional Forwarding accurate routing adjacencies such as Bidirectional Forwarding
Detection [RFC5881] and MANET Neighborhood Discovery Protocol Detection [RFC5881] and MANET Neighborhood Discovery Protocol
[RFC6130]. As a result, due to the mobility of vehicles, the network [RFC6130]. As a result, due to the mobility of vehicles, network
fragmentation is not detected quickly and the routing of packets fragmentation may not be detected quickly and the routing of packets
between vehicles or between a vehicle and an infrastructure node may between vehicles or between a vehicle and an infrastructure node may
fail. fail.
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 efficient mobility management including location points requires efficient mobility management including location
management and handover. Most vehicles are equipped with a GPS management and handover. Most 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. Note that the GPS receiver may not provide vehicles smartphone App. Note that the GPS receiver may not provide vehicles
skipping to change at page 45, line 15 skipping to change at page 45, line 15
Appendix B. Support of Multihop V2X Networking Appendix B. Support of Multihop V2X Networking
The multihop V2X networking can be supported by RPL (IPv6 Routing The multihop V2X networking can be supported by RPL (IPv6 Routing
Protocol for Low-Power and Lossy Networks) [RFC6550] and Overlay Protocol for Low-Power and Lossy Networks) [RFC6550] and Overlay
Multilink Network Interface (OMNI) [OMNI]. Multilink Network Interface (OMNI) [OMNI].
RPL defines an IPv6 routing protocol for low-power and lossy networks RPL defines an IPv6 routing protocol for low-power and lossy networks
(LLN), mostly designed for home automation routing, building (LLN), mostly designed for home automation routing, building
automation routing, industrial routing, and urban LLN routing. It automation routing, industrial routing, and urban LLN routing. It
uses a destination oriented directed acyclic graph (DODAG) to uses a destination oriented directed acyclic graph (DODAG) to
construct routing paths for hosts in a network. The DODAG uses an construct routing paths for hosts (e.g., IoT devices) in a network.
objective function (OF) for route selection and optimization within The DODAG uses an objective function (OF) for route selection and
the network. A user can use different routing metrics to define an optimization within the network. A user can use different routing
OF for a specific scenario. RPL supports multipoint-to-point, point- metrics to define an OF for a specific scenario. RPL supports
to-multipoint, and point-to-point traffic, and the major traffic flow multipoint-to-point, point-to-multipoint, and point-to-point traffic,
is the multipoint-to-point traffic. For example, in a highway and the major traffic flow is the multipoint-to-point traffic. For
scenario, a vehicle may not access an RSU directly because of the example, in a highway scenario, a vehicle may not access an RSU
distance of the DSRC coverage (up to 1 km). In this case, the RPL directly because of the distance of the DSRC coverage (up to 1 km).
can be extended to support a multihop V2I since a vehicle can take In this case, the RPL can be extended to support a multihop V2I since
advantage of other vehicles as relay nodes to reach the RSU. Also, a vehicle can take advantage of other vehicles as relay nodes to
RPL can be extended to support both multihop V2V and V2X in the reach the RSU. Also, RPL can be extended to support both multihop
similar way. V2V and V2X in the similar way.
RPL is primarily designed to minimize the control plane activity,
which is the relative amount of routing protocol exchanges versus
data traffic; this approach is beneficial for situations where the
power and bandwidth are scarce (e.g., an IoT LLN where RPL is
typically used today), but also in situations of high relative
mobility between the nodes in the network (also known as swarming,
e.g., within a variable set of vehicles with a similar global motion,
or a variable set of drones flying toward the same direction).
To reduce the routing exchanges, RPL leverages a Distance Vector
approach, which does not need a global knowledge of the topology, and
only optimizes the routes to and from the root, allowing Peer-to-Peer
(P2P) paths to be stretched. Although RPL installs its routes
proactively, it only maintains them lazily, that is, in reaction to
actual traffic, or as a slow background activity. Additionally, RPL
leverages the concept of an objective function (called OF), which
allows to adapt the activity of the routing protocol to use cases,
e.g., type, speed, and quality of the radios. RPL does not need
converge, and provides connectivity to most nodes most of the time.
The default route toward the root is maintained aggressively and may
change while a packet progresses without causing loops, so the packet
will still reach the root. There are two modes for routing in RPL
such as non-storing mode and storing mode. In non-storing mode, a
node inside the mesh/swarm that changes its point(s) of attachment to
the graph informs the root with a single unicast packet flowing along
the default route, and the connectivity is restored immediately; this
mode is preferable for use cases where Internet connectivity is
dominant. On the other hand, in storing mode, the routing stretch is
reduced, for a better P2P connectivity, while the Internet
connectivity is restored more slowly, during the time for the DV
operation to operate hop-by-hop. While an RPL topology can quickly
scale up and down and fits the needs of mobility of vehicles, the
total performance of the system will also depend on how quickly a
node can form an address, join the mesh (including Authentication,
Authorization, and Accounting (AAA)), and manage its global mobility
to become reachable from another node outside the mesh.
OMNI defines a protocol for the transmission of IPv6 packets over OMNI defines a protocol for the transmission of IPv6 packets over
Overlay Multilink Network Interfaces that are virtual interfaces Overlay Multilink Network Interfaces that are virtual interfaces
governing multiple physical network interfaces. OMNI supports governing multiple physical network interfaces. OMNI supports
multihop V2V communication between vehicles in multiple forwarding multihop V2V communication between vehicles in multiple forwarding
hops via intermediate vehicles with OMNI links. It also supports hops via intermediate vehicles with OMNI links. It also supports
multihop V2I communication between a vehicle and an infrastructure multihop V2I communication between a vehicle and an infrastructure
access point by multihop V2V communication. The OMNI interface access point by multihop V2V communication. The OMNI interface
supports an NBMA link model where multihop V2V and V2I communications supports an NBMA link model where multihop V2V and V2I communications
use each mobile node's ULAs without need for any DAD or MLD use each mobile node's ULAs without need for any DAD or MLD
skipping to change at page 47, line 35 skipping to change at page 48, line 23
Telekom), Pascal Thubert (Cisco), Carlos Bernardos (UC3M), Russ Telekom), Pascal Thubert (Cisco), Carlos Bernardos (UC3M), Russ
Housley (Vigil Security), Suresh Krishnan (Kaloom), Nancy Cam-Winget Housley (Vigil Security), Suresh Krishnan (Kaloom), Nancy Cam-Winget
(Cisco), Fred L. Templin (The Boeing Company), Jung-Soo Park (ETRI), (Cisco), Fred L. Templin (The Boeing Company), Jung-Soo Park (ETRI),
Zeungil (Ben) Kim (Hyundai Motors), Kyoungjae Sun (Soongsil Zeungil (Ben) Kim (Hyundai Motors), Kyoungjae Sun (Soongsil
University), Zhiwei Yan (CNNIC), YongJoon Joe (LSware), Peter E. Yee University), Zhiwei Yan (CNNIC), YongJoon Joe (LSware), Peter E. Yee
(Akayla), and Erik Kline. The authors sincerely appreciate their (Akayla), and Erik Kline. The authors sincerely appreciate their
contributions. contributions.
The following are co-authors of this document: The following are co-authors of this document:
Nabil Benamar Department of Computer Sciences High School of Nabil Benamar
Technology of Meknes Moulay Ismail University Morocco Phone: +212 6
70 83 22 36 EMail: benamar73@gmail.com
Sandra Cespedes NIC Chile Research Labs Universidad de Chile Av. Department of Computer Sciences, High School of Technology of Meknes,
Blanco Encalada 1975 Santiago Chile Phone: +56 2 29784093 EMail: Moulay Ismail University, Morocco, Phone: +212 6 70 83 22 36, EMail:
benamar73@gmail.com
Sandra Cespedes
NIC Chile Research Labs, Universidad de Chile, Av. Blanco Encalada
1975, Santiago, Chile, Phone: +56 2 29784093, EMail:
scespede@niclabs.cl scespede@niclabs.cl
Jerome Haerri Communication Systems Department EURECOM Sophia- Jerome Haerri
Antipolis France Phone: +33 4 93 00 81 34 EMail:
jerome.haerri@eurecom.fr
Dapeng Liu Alibaba Beijing, Beijing 100022 China Phone: +86 Communication Systems Department, EURECOM, Sophia-Antipolis, France,
13911788933 EMail: max.ldp@alibaba-inc.com Phone: +33 4 93 00 81 34, EMail: jerome.haerri@eurecom.fr
Tae (Tom) Oh Department of Information Sciences and Technologies Dapeng Liu
Rochester Institute of Technology One Lomb Memorial Drive Rochester,
NY 14623-5603 USA Phone: +1 585 475 7642 EMail: Tom.Oh@rit.edu
Charles E. Perkins Futurewei Inc. 2330 Central Expressway Santa
Clara, CA 95050 USA Phone: +1 408 330 4586 EMail:
charliep@computer.org
Alexandre Petrescu CEA, LIST CEA Saclay Gif-sur-Yvette, Ile-de-France Alibaba, Beijing, Beijing 100022, China, Phone: +86 13911788933,
91190 France Phone: +33169089223 EMail: Alexandre.Petrescu@cea.fr EMail: max.ldp@alibaba-inc.com
Yiwen Chris Shen Department of Computer Science & Engineering Tae (Tom) Oh
Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do
16419 Republic of Korea Phone: +82 31 299 4106 Fax: +82 31 290 7996
EMail: chrisshen@skku.edu URI: http://iotlab.skku.edu/people-chris-
shen.php
Michelle Wetterwald FBConsulting 21, Route de Luxembourg Department of Information Sciences and Technologies, Rochester
Wasserbillig, Luxembourg L-6633 Luxembourg EMail: Institute of Technology, One Lomb Memorial Drive, Rochester, NY
Michelle.Wetterwald@gmail.com 14623-5603, USA, Phone: +1 585 475 7642, EMail: Tom.Oh@rit.edu
Charles E. Perkins
Futurewei Inc., 2330 Central Expressway, Santa Clara, CA 95050, USA,
Phone: +1 408 330 4586, EMail: charliep@computer.org
Alexandre Petrescu
CEA, LIST, CEA Saclay, Gif-sur-Yvette, Ile-de-France 91190, France,
Phone: +33169089223, EMail: Alexandre.Petrescu@cea.fr
Yiwen Chris Shen
Department of Computer Science & Engineering, Sungkyunkwan
University, 2066 Seobu-Ro, Jangan-Gu, Suwon, Gyeonggi-Do 16419,
Republic of Korea, Phone: +82 31 299 4106, Fax: +82 31 290 7996,
EMail: chrisshen@skku.edu, URI: https://chrisshen.github.io
Michelle Wetterwald
FBConsulting, 21, Route de Luxembourg, Wasserbillig, Luxembourg
L-6633, Luxembourg, EMail: Michelle.Wetterwald@gmail.com
Author's Address Author's Address
Jaehoon (Paul) Jeong (editor) Jaehoon (Paul) Jeong (editor)
Department of Computer Science and Engineering Department of Computer Science and Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon Suwon
Gyeonggi-Do Gyeonggi-Do
16419 16419
 End of changes. 20 change blocks. 
62 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/