Subject: [MEXT] Put it straight (draft-ietf-mext-nemo-ro-automotive-req-01.txt)

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Nov 2008 12:54:32 +0100

MEXTers,

Let's first make one thing straight about 
draft-ietf-mext-nemo-ro-automotive-req-01.txt.

Are the requirements written such as the  RO vehicular design uses 
Correspondent Routers as mentioned in draft-bernardos-mext-nemo-ro-cr-00 
and in draft-wakikawa-mext-cr-consideration-0?

This text in the RO-automotive draft makes think so:
>    With respect to the classification of NEMO Route Optimization
>    scenarios described in [RFC4889], the non-nested NEMO RO case
>    (Section 3.1) is considered as the most important for the automotive
>    deployment.
rfc4889 section 3.1:
>    The Non-Nested NEMO Route Optimization involves a Mobile Router
>    sending binding information to a Correspondent Entity. [...]   The
>    Correspondent Entity can be a Correspondent Node or a Correspondent
>    Router.  The interesting case is when the Correspondent Entity is a
>    Correspondent Router.  With the use of Correspondent Router, Route
>    Optimization session is terminated at the Correspondent Router on
>    behalf of the Correspondent Node.  As long as the Correspondent
>    Router is located "closer" to the Correspondent Node than the Home
>    Agent of the Mobile Router, the route between Mobile Network Node and
>    the Correspondent Node can be said to be optimized.  For this
>    purpose, Correspondent Routers may be deployed to provide an optimal
>    route as illustrated in Figure 1.

Along the same lines: is the RO-vehicular technique designed following 
these requirements supposed to use Mobile IPv6 extensions?  Like 
extending BUs/BAcks?  Or can it use some other existing protocol as basis?

Alex
PS: I will provide comments separately on
     draft-ietf-mext-nemo-ro-automotive-req-01.txt but first let's
     clarify the above points.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 28 Nov 2008 13:07:50 +0100

Alex,

Alexandru Petrescu escribió:
> Correspondent Routers as mentioned in 
> draft-bernardos-mext-nemo-ro-cr-00 and in 
> draft-wakikawa-mext-cr-consideration-0?
well a requirement doc should be neutral w.r.t. the solution

In draft-bernardos, there is a RO correpsondetn entity, that performs 
the RO fucntions in the CN side, which can be placed in different 
device, including the CN itself, the HA or a new device, like the CR.
I think that it is importnat to differentiate the fucntional entities 
that are required in any solutions and the particular form and places 
that these fucntions are placed in the different solutions

> extending BUs/BAcks?  Or can it use some other existing protocol as 
well, we are in mext, so we work on mip6

regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Nov 2008 14:03:18 +0100

> well a requirement doc should be neutral w.r.t. the solution

I fully agree, but it does not seem the case with this requirements
document.  It assumes a Correspondent Router.

>  I think that it is importnat to differentiate the fucntional 
> entities that are required in any solutions and the particular form 
> and places that these fucntions are placed in the different solutions
> 
Extending the concept of RO correspondent entity, to a Correspondent
Router and further to a Mobile Router is superfluous to me.  If we need
Mobile Router to Mobile Router communication we don't need to talk about
Mobile Router being a Correspondent Router.  It's simply Mobile Router
to Mobile Router communication.

>> Along the same lines: is the RO-vehicular technique designed 
>> following these requirements supposed to use Mobile IPv6 
>> extensions?  Like extending BUs/BAcks?  Or can it use some other 
>> existing protocol as basis?
>> 

I don't think Mobile IPv6 is well adapted for car-to-car communications,
without fixed infrastructure.

Mobile IPv6 has many topological assumptions (a fixed HA, an often fixed
CN) that make it difficult to use in a car-to-car communications.

I believe car-to-car communications are a significant departure from
Mobile IPv6.

We can achieve car-to-car communications by using Mobile Router to
Mobile Router communications by their egress interfaces and without
using Mobile IPv6.

If it is believed that Mobile IPv6 should be modified in order to
achieve car-to-car communications then I fully disagree.

Alex

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 28 Nov 2008 14:56:47 +0100

> to Mobile Router communication.
no, the correspondet router does not need to be mobile (like the CN does 
not need to be mobile neither)

> without fixed infrastructure.
ok, so i suggest you to go an propose your ideas in the wg that has a 
protocol that according to you is well suited for car to car 
communication, cause in this wg, we usually work on mip6 :-)

regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Nov 2008 15:24:23 +0100

[...]
>> Extending the concept of RO correspondent entity, to a 
>> Correspondent Router and further to a Mobile Router is superfluous 
>> to me.  If we need Mobile Router to Mobile Router communication we 
>> don't need to talk about Mobile Router being a Correspondent 
>> Router.  It's simply Mobile Router to Mobile Router communication.
> 
> no, the correspondet router does not need to be mobile (like the CN 
> does not need to be mobile neither)

Marcelo why do we need to talk about a Correspondent Router when we talk
Mobile Router to Mobile Router communication?

>> I don't think Mobile IPv6 is well adapted for car-to-car 
>> communications, without fixed infrastructure.
>> 

Note taken.  I take this as a Chair indication to not touch other
protocols when doing Mobile IPv6 for car-to-car communications (without
infrastructure).

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 28 Nov 2008 15:34:47 +0100

>> document.  It assumes a Correspondent Router.
The document is using the established NEMO Terminology (RFC 4885) and CR 
is corresponding to section
2.9.  Correspondent Router (CR)  . . . . . . . . . . . . . . . .  7
of RFC 4885.
Actually, draft-ietf-mext-nemo-ro-automotive-req-01.txt is mostly using 
the term CE (Correspondent Entity) which is by nature neutral (could be 
fixed or mobile): in the automotive use-case we are dealing with 
scenarios where we really mean MR to MR communications which must be 
optimized; and there are also other scenarios where we want to optimize 
communications between a MR and a nearby CN. There could be one solution 
for the two cases, or a common solution. For a specific MR-MR solution 
it doesn't make sense to use the term CR.

> does not need to be mobile neither)
Agree.

>> without fixed infrastructure.
One has to understand that cars may be once in an infrastructure-less 
situation and once in an infrastructure-based situation and they also 
must be reachable at a permanent  address (therefore IPv6 and NEMO). ITS 
architectures are designed in a way both are supported (so, there could 
be different solutions but they have to co-exist in a single architecture).

>> achieve car-to-car communications then I fully disagree. 

Alex has a point indeed, but may be not the background. Car-to-Car 
communication would both need an NEMO-type of solution (with HA, CoA, 
etc - note that I avoided to use Mobile IPv6 because we need to support 
in-vehicle networks) which is optimized for car-to-car communications 
and an MANET-type of solution where there is no HA. The first has to be 
dealt with MEXT, the second possibly with Autoconf.

Thierry

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 28 Nov 2008 15:34:57 +0100

Alexandru Petrescu escribió:
>>> Router and further to a Mobile Router is superfluous to me.  If we 
>>> need Mobile Router to Mobile Router communication we don't need to 
>>> talk about Mobile Router being a Correspondent Router.  It's simply 
>>> Mobile Router to Mobile Router communication.
>>

I think i understnad where the misunderstanding is. Are you considering 
only the car to car communication? Cause i understnad that the scenario 
that we are considering is broader than that and it allows the car to 
communicate to the fixed infrastrcutre as well, so, in that case, we 
need to CE as a general concept, agree?
> protocols when doing Mobile IPv6 for car-to-car communications (without
no, this is not what is said. What i said is that in MEXT we work in 
mip6/nemo based solutions and not on solutions that don't involve MIP6/nemo
If in order to make a MIP6/nemo solution to work properly we need to 
have extensions in other protocols, that's perfectly ok (see for 
instance the work we have done with dhcp pd, and so on)

regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Nov 2008 17:20:27 +0100

marcelo bagnulo braun wrote:
>> marcelo bagnulo braun wrote: [...]
>>>> Correspondent Router and further to a Mobile Router is 
>>>> superfluous to me.  If we need Mobile Router to Mobile Router 
>>>> communication we don't need to talk about Mobile Router being a
>>>>  Correspondent Router.  It's simply Mobile Router to Mobile 
>>>> Router communication.
>>> 
>>> no, the correspondet router does not need to be mobile (like the 
>>> CN does not need to be mobile neither)
>> 
>> Marcelo why do we need to talk about a Correspondent Router when we
>>  talk Mobile Router to Mobile Router communication?
> 
> I think i understnad where the misunderstanding is. Are you 
> considering only the car to car communication?

YEs.

> Cause i understnad that the scenario that we are considering is 
> broader than that and it allows the car to communicate to the fixed 
> infrastrcutre as well, so, in that case, we need to CE as a general 
> concept, agree?

Well I thought we would rather design a purpose-specific method of RO,
adapted for particular cases, rather than a generic RO method.  In this
sense I don't agree a generic vehicular RO method would work for all
vehicular scenarios.

>>> ok, so i suggest you to go an propose your ideas in the wg that 
>>> has a protocol that according to you is well suited for car to 
>>> car communication, cause in this wg, we usually work on mip6 :-)
>> 
>> protocols when doing Mobile IPv6 for car-to-car communications 
>> (without infrastructure).
>> 
> mip6/nemo based solutions and not on solutions that don't involve 
> MIP6/nemo If in order to make a MIP6/nemo solution to work properly 
> we need to have extensions in other protocols, that's perfectly ok 
> (see for instance the work we have done with dhcp pd, and so on)

Ah, that's right.  In this sense, an RO method for car-to-car
communications that wouldn't extend Mobile IPv6 (but some other
protocol), could be designed here maybe.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Nov 2008 17:30:39 +0100

Hi Thierry,

Thierry Ernst wrote:
>>>>> Are the requirements written such as the  RO vehicular design
>>>>>  uses Correspondent Routers as mentioned in 
>>> I fully agree, but it does not seem the case with this 
>>> requirements document.  It assumes a Correspondent Router.
> The document is using the established NEMO Terminology (RFC 4885) and
>  CR is corresponding to section 2.9.  Correspondent Router (CR)  . .
>  . . . . . . . . . . . . . .  7 of RFC 4885.

Well yes, but the term CR isn't used neither by Mobile IPv6 nor by its
extension NEMOv6.  We could of course define new terms informationally,
but sometimes  it is good to shortcut many definitions by terms actually
used in implementations.

We already have to talk OBU to mean MR - if we define CE or CR to be yet
another term for the same thing then it's maybe a lot...  or depends on
how people get this altogether... just some thought.

> Actually, draft-ietf-mext-nemo-ro-automotive-req-01.txt is mostly 
> using the term CE (Correspondent Entity) which is by nature neutral 
> (could be fixed or mobile): in the automotive use-case we are dealing
>  with scenarios where we really mean MR to MR communications which 
> must be optimized;

Well I agree, but in this particular car-to-car communication it is very
meaningful to just mean MR or OBU.  The term Correspondent Router isn't
used by any protocol like NEMOv6 or Mobile IPv6.

> and there are also other scenarios where we want to optimize 
> communications between a MR and a nearby CN.

YEs I agree.  I agree that a scenario needing to optimize routes between
MR and CN in the fixed infrastructure needs Mobile IPv6 extensions.

> There could be one solution for the two cases, or a common solution.

I disagree in this case.  I don't see the use of Mobile IPv6 for
car-to-car communications (without fixed infrastructure).  It's like
forcing the use of the hammer even on small things, smaller than nails.

> For a specific MR-MR solution it doesn't make sense to use the term 
> CR.

I agree.  MR-to-MR solution wouldn't mention CR.

Alex

> 
> 
> 
>>> 
>>>> In draft-bernardos, there is a RO correpsondetn entity, that 
>>>> performs the RO fucntions in the CN side, which can be placed 
>>>> in different device, including the CN itself, the HA or a new 
>>>> device, like the CR. I think that it is importnat to 
>>>> differentiate the fucntional entities that are required in any 
>>>> solutions and the particular form and places that these 
>>>> fucntions are placed in the different solutions
>>>> 
>>> Correspondent Router.  It's simply Mobile Router to Mobile Router
>>>  communication.
>>>>> extensions?  Like extending BUs/BAcks?  Or can it use some 
>>>>> other existing protocol as basis?
>>>>> 
>  situation and once in an infrastructure-based situation and they 
> also must be reachable at a permanent  address (therefore IPv6 and 
> NEMO). ITS architectures are designed in a way both are supported 
> (so, there could be different solutions but they have to co-exist in 
> a single architecture).
> 
>>> 
>> ok, so i suggest you to go an propose your ideas in the wg that has
>>  a protocol that according to you is well suited for car to car 
>>> Mobile IPv6 has many topological assumptions (a fixed HA, an 
>>> often fixed CN) that make it difficult to use in a car-to-car 
>>> communications.
>>> 
>>> I believe car-to-car communications are a significant departure 
>>> from Mobile IPv6.
>>> 
>>> We can achieve car-to-car communications by using Mobile Router 
>>> to Mobile Router communications by their egress interfaces and 
>>> without using Mobile IPv6.
>>> 
>  etc - note that I avoided to use Mobile IPv6 because we need to 
> support in-vehicle networks) which is optimized for car-to-car 
> communications and an MANET-type of solution where there is no HA. 
> The first has to be dealt with MEXT, the second possibly with 
> Autoconf.
> 
> Thierry
> 
> 
> 
> 
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 29 Nov 2008 21:09:28 +0100

> sense I don't agree a generic vehicular RO method would work for all
right, but i understand that the automotive case, they also want to 
communicate the nodes in the car network to the fixed infrastrcuture, so 
not only car to car communications need to be considered.

> protocol), could be designed here maybe.
not sure what you have in mind so, i guess the best approahc is for you 
to describe what you have in mind in more detail and then we cna figure 
out if this is the right wg for that work

regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 29 Nov 2008 23:02:22 +0100

marcelo bagnulo braun wrote:
>> Well I thought we would rather design a purpose-specific method of
>> RO, adapted for particular cases, rather than a generic RO method.
>> In this sense I don't agree a generic vehicular RO method would
>> work for all vehicular scenarios.
>> 
> communicate the nodes in the car network to the fixed infrastrcuture,
> so not only car to car communications need to be considered.

I agree, the automotive case often considers also the case of nodes in
the car network communicating to the fixed infrastructure.  Often the
first steps in that direction is to see how IPv6 can run over the
vehicular links towards the infrastructure, and also often mobility as
handover between subnets is not considered in these first steps.

>>>>> ok, so i suggest you to go an propose your ideas in the wg
>>>>> that has a protocol that according to you is well suited for
>>>>> car to car communication, cause in this wg, we usually work
>>>>> on mip6 :-)
>>>> 
>>>> Note taken.  I take this as a Chair indication to not touch
>>>> other protocols when doing Mobile IPv6 for car-to-car
>>>> communications (without infrastructure).
>>>> 
>>> no, this is not what is said. What i said is that in MEXT we work
>>> in mip6/nemo based solutions and not on solutions that don't
>>> involve MIP6/nemo If in order to make a MIP6/nemo solution to
>>> work properly we need to have extensions in other protocols,
>>> that's perfectly ok (see for instance the work we have done with
>>> dhcp pd, and so on)
>> 
> not sure what you have in mind so, i guess the best approahc is for
> you to describe what you have in mind in more detail and then we cna
> figure out if this is the right wg for that work

What I have in mind is to look closer at how IPv6 can be deployed in the
vehicular types of deployments.

I think we need the req document for vehicular RO, I offered comments,
and also think we can add some simpler aspects to the reqs document; for
example the necessity of requiring IPv6 to run over 802.11p, and the
necessity of requiring car-to-car communications without using Mobile 
IPv6 - in a first step.  In a first step these should be accomodated 
without the mobility necessity.

These comments come after having read the RO vehicular reqs in detail, 
and after having had just a little exposure to the vehicular standards.

Speaking of which - do you think in MEXT we can work with non-IETF 
vehicular standards without having access to these standard documents 
(IEEE 802.11p and ISO CALM)?  Where are these documents?

Alex

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 30 Nov 2008 12:09:35 +0100

> handover between subnets is not considered in these first steps.
well, this is decision that the WG can take i.e. to scope the problem 
and focus in some parts of it, but this is up for disucssion (this issue 
wasn't brought up until now afaict)

> without the mobility necessity.
I guess that we need to run IP on the first place, but i am not sure i 
understand what the problems are with that...

> (IEEE 802.11p and ISO CALM)?  Where are these documents?
mmm, i guess we usually work with link layers that are not defined by 
the ietf, so i don't see what is the problem with that... i mean, the 
IETF haven't defined ethernet but still we have defined arp and ND...

regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 30 Nov 2008 18:29:33 +0100

> IETF haven't defined ethernet but still we have defined arp and ND...

I agree, we work with link layers that are not defined by IETF.  For 
Ethernet we have public free access to Ethernet standard documents.  I'm 
afraid there may not be public access for latest 802.11p documents, 
neither ISO CALM documents.  Maybe we could  obtain this access 
restricted to the MEXT WG members somehow.

Alex

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 30 Nov 2008 18:41:16 +0100

We can ask, certainly
C2C has appointed a liaison with the MEXT wg, so we can try that...
Regards, marcelo

Alexandru Petrescu escribió:
>>> vehicular standards without having access to these standard 
>>> documents (IEEE 802.11p and ISO CALM)?  Where are these documents?
>>>
> Ethernet we have public free access to Ethernet standard documents.  
> I'm afraid there may not be public access for latest 802.11p 
> documents, neither ISO CALM documents.  Maybe we could  obtain this 
> access restricted to the MEXT WG members somehow.
>
> Alex
>
>