Subject: Re: [its] charter ITS

From: "Z.W. Yan" <[email-masked]>
Date: Fri, 8 Apr 2016 09:03:14 +0800

Hi, All,
About the charter, I think we should also consider and describe the NEMO and nested-NEMO scenarios and protocols.
Otherwise, it just falls back to the application of plain MIP/PMIP no matter in the V2V case or V2I case. 
BR,
Zhiwei Yan

2016-04-08 

Z.W. Yan

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Apr 2016 11:03:26 -0300

Le 07/04/2016 22:03, Z.W. Yan a écrit :
> Hi, All, About the charter, I think we should also consider and
> describe the NEMO and nested-NEMO scenarios and protocols.

Zhiwei Yan,

I disagree with you saying it's just a plain MIP.

There is currently a 'gap analysis' part, section 14.2 'Mobile IP':
https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-04#page-15

For Mobile IP:
- currently a car can't send a BU to another car if the HA is absent
   (out of LTE coverage).  That's an old Route Optimization problem in
   MIP.

Do you agree with this gap?

And, to be more clear, this should _not_ lead to developping extensions
of Mobile IP to solve this V2V case, because there are other bigger
problems I can describe separately.  One of these relates to security.

Alex

>
> BR, Zhiwei Yan 2016-04-08
> ------------------------------------------------------------------------
>
>
>
Z.W. Yan
>
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 11 Apr 2016 09:51:37 +0200

Dear ITSers,

I would not focus to MIP (only or even at all) for handling IPv6
connectivity for moving vehicles before having *clearly*  defined the type
of link and data traffic model that will be used by connected cars. 

For example, if we assume pure MIP, it represents a good strategy if you
want to keep an IP connectivity 'open' while the car moves...and this,
regarding if and how many 'bits' are actually transmitted. So, considering
what we have 'today' as data model for connected cars, it is more related to
M2M-type of traffic (small packets, sensor-type update)..so, using MIP for
this would cost a lot in overhead for very small benefit in terms of data.
The challenge here would indeed be to improve the RO and reduce the
overhead...but is it really required??

On the other side, DMM-type MIP will not keep a link open if not used and
will only handle IPv6 mobility for active links. That would imply that the
M2M-type of traffic will not have an IPv6 mobility management, but quick
IPv6 link establishment when M2M traffic is required to be transmitted.
Here, the challenge is related to quick prefix/DHCP and DNS handling when
under coverage and while M2M data is to be transmitted (possibly with one
handover in between). This sounds more what we will have...and maybe more
urgent to address than handling mobility.

And you could also consider that PMIP-type of mobility management be more
adapted to connected vehicles, as it could natively 'hide' mobility to the
applications...

Now, if we have more 'stream-like' communication, how long is such link
active? How many 'handovers' could be required to handle this IPv6 link
(under typical mobility and considering small or medium cells) ? 

My point is we should not putting the cart before the horse, and first
define what we understand as an IPv6 'link' in a vehicular context, as well
as defining what would be the typical traffic models that will be there...(I
know that IETF would like to be agnostic to a type of traffic model, but
that might not be possible in a vehicular context..). 

Then only we can look at the gaps between currently existing IPv6
technologies...

Best Regards,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 08 April 2016 16:03
To: [email-masked]
Subject: Re: [its] charter ITS

Zhiwei Yan,

For Mobile IP:

And, to be more clear, this should _not_ lead to developping extensions of
Mobile IP to solve this V2V case, because there are other bigger problems I
can describe separately.  One of these relates to security.

Alex

Z.W. Yan
> [email-masked] https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/its