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

["Templin (US), Fred L" <[e-mail]>]

Hi Paul,

See below for responses:

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

OK.

>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             |
>+-----------------+---------------------------------+

Close enough, yes.

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

OK.

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

The OMNI MN model can apply to any category of MN, from large vehicles
down to individual pedestrians with pros and cons to consider as you say.
But, it is not necessarily for vehicles only.

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

The pedestrian's smartphone can act like a MN the same as for an auto,
truck, taxi, bicycle, etc. And, can then use the MNP to number any attached
devices (bluetooth, etc.) and/or any virtual internal networks and/or
applications. So, the MN does not need to have a physical moving network
inside but can still benefit from having a MNP.

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

There can be considered to be two classes of nodes - those that connect to
the OMNI link, and those that connect only to the global IPv6 Internet. The
two classes of devices can communicate with each other via a "gateway"
provided by the OMNI link mobility service, but only those on the OMNI
link are able to benefit from a true multilink capability.

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

If so, it would be good to balance it with a discussion of the benefits
offered by the OMNI multilink service.

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

OK.

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

OK.

Thanks - Fred

>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