Re: [6lo] New I-D draft-delcarpio-6lo-wlanah-00.txt

[Alexandru Petrescu <[e-mail]>]

Dear Felipe,

Le 18/06/2015 18:16, Felipe Del Carpio a écrit :
[...]

>> But I dont think running at 863MHz will save any much energy,
>> instead of running at 2.4GHz.
>
> [FDC] Indeed lower frequencies do not alone reduce battery
> consumption. However, the propagation at lower frequencies for a
> radio signal is better meaning that less transmit power at the
> device's antenna is needed to yield the same
> distance/range/coverage.

I agree in general.  That is about places where these devices are
supposed to work.

> The 802.11ah saves energy by allowing devices to sleep (doze) as
> mentioned in the draft. These techniques which allow devices to sleep
> are key power saving mechanisms.

Ok, sleeping is fine to save energy.  But I dont think sleeping requires HC.

[...]

>> In that sense, I dont think there is anything to do to modify IPv6
>>  to work on it. (and yes, IPv6 must work ok on 11ah, as it works on
>>  WiFi, and it is worth documenting in a document).
>
> [FDC] In the draft it is clearly stated that LLC allows 802.11ah to
> use IPv6 by default.

I guess you talk about this text in the draft:
> IPv4 and IPv6 are compatible with 802.11ah via the LLC.

I fully agree.

But the draft further says:
> However, this technology presents a trade-off between energy savings
> and bit rate of the link.

I dont understand.  The LLC (Logical Link Control) headers dont contain
bitrate nor energy savings.  What do you mean more precisely?

> Consequently, 6LoWPAN techniques are beneficial to reduce the
> overhead of transmissions, save energy and get a better throughput.

Because I dont understand the above (LLC contain bitrate or energy
savings?) I dont understand why 6lowpan techniques are beneficial.

> You have a point in the lower bitrate of 802.11ah. Actually, this
> makes 802.11ah a perfect candidate for IPv6 header compression. If
> packets are expected to be small, why we would like to send a large
> IPv6/UDP/whatever headers?.

I agree in general it is questionable to send 40bytes of IPv6 Base
Header together with a byte of useful temperature value.

But the IPv6 Base Header contains fields which allow the 11ah node
to be fully connected to the entire Internet.

Would one want the 11ah node to be fully connected to any other 11ah
node in the Internet?  Or not?

If the app data needs to be sent locally only (i.e. from my remote
control unit to my door thermometer) then one wouldnt need IPv6 Base
Header at all, no IPv6 addresses either, no IPv6 altogether.

If on the other hand one wants IPv6 to work because the applications are
very easy to program on widely available cheap socket interfaces, with
much programming skillset available on market - then I must use the
entire IPv6 Base Header.  One cant come without the other.

> We want IPv6 enabled devices, but with compressed headers.

I am trying to parse but it's hard.

An IPv6 enabled device has IPv6 Base Headers mandatory.

Compressed headers (LOWPAN_IPHC) means there are no IPv6 Base Headers.
That means no IPv6.

I am confused by that.

But I agree we want a document that tells how to run IPv6 over 802.11ah.
  But I disagree to make that document too smart.

[...]

>>> [FDC] Indeed, the energy saving mechanisms are useful for
>>> battery operated devices like a Smartphone. Also connected
>>> sensors such as temperature sensors could be connected to
>>> internet through an 802.11ah link.
>>
>> If you agree this is for a smartphone, it would be good to note
>> that a smartphone can not get a shorter-than-64 prefix from a
>> cellular operator, and as such can not send an RA containing a /64
>>  on its 11ah interface - it will have to send a /65 in that RA.
>> Because of that an 11ah sensor connecting to the 11ah interface of
>>  the smartphone and forming an IID of length 64 will lead to IPv6
>> address of length 129. That can not work.
>
> [FDC] We need to study further this point. Do you have references
> that could enlighten us more with this respect? Maybe, implementation
> documentation?

YEs, the implementation is widely available.

Use linux/android on any smartphone.  Connect to any IPv6-enabled
cellular network.  Obtain an IPv6 address.  Type ifconfig -a.  See the
prefixlen is /64.  Listen to RAs with wireshark see the plen field in RA
is /64.  If you need I can send you a packet dump showing that.

All IPv6-enabled cellular networks act that way.  There isn't any which
would provide a shorter-than-64 prefix, or that would answer to DHCPv6
Prefix Delegation requests.

If all one gets from the access network is a /64, one can not make an
additional /64 out of it to put on the 11ah interface, so one is forced
to put a /65 in the 11ah interface.

This situation is approximately similar in many IPv6 WiFi hotspot
deployments: connect an IPv6 smartphone on an IPv6 hotspot in public
areas, at work, in many places, and note this /64.  But I did encounter
some exceptions of shorter-than-64 prefixes given to smartphones on
WiFi.  Never on cellular.

Is this explanation sufficient?  Can I clarify?

>> Also, an 11ah sensor would like to be able to talk using IPv6 to
>> its 11b-only neighbor, both one the same hotspot emitted by a
>> smartphone equipped of one single interface featuring all
>> 11b/g/n/ac/ad/ah characteristics.  Right?
>>
> [FDC] I think IPv6 will be this interface. 11ah talks IPv6 and other
>  11b device in the subnet talks IPv6, then they interoperate. We are
>  discussing the 6LoWPAN which is the adaptation layer before IPv6 in
>  11ah devices.

But an IPv6 11ah device will strip the IPv6 Base Header before sending
the packet to an 11b device in the same subnet (ad-hoc mode).  And no
11b device implements LOWPAN_HC so it can't reconstruct the IPv6 Base
Header.

Am I missing something?

Alex