Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Fred,
I sincerely appreciate your good suggestion and comments for our IPWAVE PS
draft. .
I put my comments on your input inline.

> Hi, I read this draft and have some comments. In the aviation domain, we
are designing
> an Aeronautical Telecommunications Network with Internet Protocol
Services (ATN/IPS)
> with the goal of having a worldwide IPv6 Internetwork interconnecting
aircraft, air traffic
> controllers and other authorized entities. This work is focused in the
International Civil
> Aviation Organization (ICAO), but is now being brought into the IETF:
>
> https://datatracker.ietf.org/liaison/1676/
> https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/
> https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/
>
> However, the vehicular network model we have for the airplanes differs
significantly from
> the vehicular model in this ipwave draft when in fact I think there
should be no difference.
>

I think that your link model based on OMNI and SPAN is a good candidate for
as a vehicular link model.
A mobile node (MNM) with an OMNI interface in your OMNI draft plays a role
of a mobile router,
which is named IP-OBU in the IPWAVE PS draft:
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-14#page-14

The vehicular network architecture in the IPWAVE PS draft is similar to
your architecture in
the OMNI draft in the following mapping:
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-14#page-11

+-----------------+---------------------------------+
| IPWAVE PS Draft | OMNI Draft                      |
+=================+=================================+
| IP-RSU          | AR (Access Router)              |
+-----------------+---------------------------------+
| IP-OBU          | MN (Mobile Node)                |
+-----------------+---------------------------------+
| Moving Network  | EUN (End User Network)          |
+-----------------+---------------------------------+
| Mobility Anchor | MSE (Mobility Service Endpoint) |
+-----------------+---------------------------------+
| Vehicular Cloud | INET Routing System             |
+-----------------+---------------------------------+

> In particular, in the ATN/IPS aircraft are statically configured with a
Mobile Network
> Prefix (MNP) (sort of like a VIN) that travels with the aircraft wherever
it goes. It uses
> this MNP to form a unique link-local address, then assigns the address to
the OMNI
> interface which is a virtual interface configured over the wireless data
link interfaces.

In the IPWAVE PS draft, there is no discussion on Mobile Network Prefix
(MNP) for
a moving network in a vehicle, but the delegation and configuration of the
MNP can be
included in the IPWAVE PS draft in the next revision.

> Then, on the wireless links themselves, there are no on-link prefixes and
no PIOs
> advertised by access routers. The wireless links therefore carry only
link-local or
> MNP-addressed IPv6 packets, therefore no two vehicles will appear to be
on the
> same subnet and no multi-link issues for subnet partitions and merges
occur. Also,
> DAD is not needed at all due to the unique assignment of MNPs.
>

The usage of ULA (Unique Local Address) for the OMNI interface in the SPAN
is a good solution for the multihop routing in the entire OMNI link of the
SPAN.
However, this is just a candidate for vehicular networks.
As in the IPWAVE PS draft, a global IPv6 address can also be used for the
wireless link
for IP-OBU and IP-RSU.

There are pros and cons of the OMNI draft and the IPWAVE PS draft.
As you said, indeed, the IPv6 address autoconfiguration based on MNP does
not need DAD
because a unique IPv6 can be derived from the MNP and Interface ID (for MN)
and
the MNP and MSID (for AR and MSE).

However, in V2P (Vehicle-to-Pedestrian Communication) scenario, a
pedestrian's smartphone
needs to have an OMNI interface for the communication through the SPAN even
though
it does not have a moving network inside it.

As described in the IPWAVE draft, if the wireless link uses a global IPv6
prefix,
the smartphone does not need the OMNI link to communicate with a host
within a moving
network in a vehicle.

As a requirement for the IPWAVE draft, we can say that the configuration
and control
overhead for V2P or V2X should be minimized.

> This same model could be applied to ipwave vehicles, and would alleviate
the problems
> stated in Section 5. In particular, the link model could adopt the OMNI
link model (see
> the OMNI draft) where all nodes within the transportation system are
"neighbors" on
> a shared NBMA virtual link. IPv6 ND works with no modifications, and the
link model is
> always connected. So, there would be no need for vehicular extensions to
IPv6 and ND.
> Likewise, mobility management services would work the same as the ATN/IPS
design
> and would not require any adaptations for fast-moving vehicles.
>

As you said, as another requirement in the IPWAVE draft, we can say that
the
vehicular link model needs to minimize the changes of IPv6, ND, and
Mobility Management.

> Final comment for now - the document lists only MIPv6 and PMIPv6 as
example
> mobility services. We are considering them in the aviation domain, but
also have
> AERO and LISP as candidate services. Since these would also apply in the
ipwave
> case, it would be good to list them as candidates here also.
>

Sure, the IPWAVE PS draft can have AERO and LISP for mobility services.

Thanks for your good input.

Best Regards,
Paul

> Fred

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>