Subject: Re: [MEXT] Access to CALM and 802.11p documents

From: Thierry Ernst <[email-masked]>
Date: Mon, 01 Dec 2008 11:14:15 +0100

Alex, all,

CALM is an architecture, so there are documents from the link layer up 
to the application layers, but these are not published yet so not public 
either. The document must be stable enough before it could be 
distributed. There is an underlying liaison statement between ISO and 
IETF but it needs to proceed through the ISO secretariat and I don't 
know what is the current status.  Once the liaison is established access 
to documents should be provided.

Regards,
Thierry

Alexandru Petrescu wrote:
> marcelo bagnulo braun wrote:
> [...]
>>> 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?
>>>
>> 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...
>
> 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
>
>
> ______________________________________________________________________
> 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

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

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 01 Dec 2008 16:44:07 +0100

Alexandru Petrescu wrote:
> Hi Thierry,
> Thierry Ernst wrote:
>>> Alexandru Petrescu escribió:
>>>>> Alex,
>>>>> Alexandru Petrescu escribió:
>>>>>> 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?
>>>>>
>>>>> 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.
>> 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.
CR is of course not used in Mobile IPv6 (it was defined after Mobile 
IPv6) nor in NEMO BS (RFC 3963 is not dealing with RO). On the other 
hand it is used in the RO problem scope and RO solution analysis 
documents, and in RO solutions. So it is used.

(I remember how much you opposed with this term so let's not argue about 
this anymore. All of us have things we didn't agree upon but which were 
agreed by a higher number of people).
>
> 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, the car industry has difficulty to call an OBU a MR (or a MR 
an OBU). So, in this specific situation, a new term is needed. 
Currently, the term "ITS station" seems to take momentum. An "ITS 
station" is either a router, or a router and a set of hosts. The 
advantage of this new term is that the car industry does not need to 
refine the definition of OBU and the IETF folks don't have to refine the 
definition of MR. Things happen.
>
>> 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.
I don't get it. Cars will be NEMO-enabled and when two cars talk 
together they will be in situations where they would do this over NEMO 
(cars not nearby) or they would need to skip NEMO (cars nearby). Both 
are RO situation; the solution may not be NEMO-like particularly in the 
second case but they will need to interoperate with NEMO (a decision to 
use the NEMO tunnel or not will be needed at the MR - if it doesn't use 
the tunnel to HA I call this RO from the point of view of NEMO).
>
>> 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.

Thierry.

>
> 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
>>>>>
>>>> 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)
>> Agree.
>>
>>>
>>>>
>>>>>> 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?
>>>>>>
>>>>> well, we are in mext, so we work on mip6
>>>>
>>>> I don't think Mobile IPv6 is well adapted for car-to-car 
>>>> communications, 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).
>>
>>>>
>>> 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
>>>
>>>> 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 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: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Dec 2008 20:57:42 +0100

Hi Thierry,

Thierry Ernst wrote:
[...]
[...]
> Actually, the car industry has difficulty to call an OBU a MR (or a
> MR an OBU). So, in this specific situation, a new term is needed. 
>  refine the definition of OBU and the IETF folks don't have to refine
> the definition of MR. Things happen.

If 'ITS station' makes sense an dhelp in building relevant IP
requirements then I agree with it.

[...]
>> car-to-car communications (without fixed infrastructure).  It's
>> like forcing the use of the hammer even on small things, smaller
>> than nails.
> 
> together they will be in situations where they would do this over
> NEMO (cars not nearby) or they would need to skip NEMO (cars nearby).
> Both are RO situation; the solution may not be NEMO-like particularly
> in the second case but they will need to interoperate with NEMO (a
> decision to use the NEMO tunnel or not will be needed at the MR - if
> it doesn't use the tunnel to HA I call this RO from the point of view
> of NEMO).

YEs, have MR-to-MR communication would need to interoperate with NEMO 
implementations when infrastructure is in the picture.  There's probably 
an interoperation issue, make sure the MR-to-MR mechanism works ok with 
NEMO, I agree.

But I also think there may be vehicles which rarely if ever connect to 
infrastructure, but their main task would be car-to-car communication, 
in which case a NEMO type of RO extension for infrastructure wouldn't be 
needed in these cases.

Alex