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

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

Fred,
I think all your responses below  make sense.
I will try to  address all your comments on the revision of our IPWAVE PS
draft.

Thanks.

Paul

2020년 4월 22일 (수) 오전 7:22, 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
>