From: Michael Richardson <mcr@sandelman.ca>
To: Alexander Aring <alex.aring@gmail.com>
Cc: linux-wpan@vger.kernel.org
Subject: iphc, rfc6553/6554 and 6lo ESC discussion
Date: Fri, 31 Jul 2015 20:45:31 -0400 [thread overview]
Message-ID: <6541.1438389931@sandelman.ca> (raw)
In-Reply-To: <1438346288-14546-1-git-send-email-alex.aring@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]
{trimmed CC list}
Alexander Aring <alex.aring@gmail.com> wrote:
> check the LL type which can be currently BTLE or IEEE802154. This could
> be useful to make different handling in iphc compress/decompress and
> evaluating LL private data of skb control block "skb->cb".
Speaking of iphc compression, the IETF 6lo WG is currently looking at ways
to expand the available HC and NHC space. This is mostly so that the ROLL WG
(which I co-chair) can then define a way to compress the RH3 and RPI headers
(and the IPIP header required to insert those).
It would be great to have more people writing code in this discussion.
If you need more pointers to the discussion, or even if you want to have a
G+/Jitsi/etc. meeting to understand the *why* of the discussion, let me know.
> The handling is currently for 802.15.4 is in generic 6lowpan code
> currently not quite. This should be handled by private data. At the
> moment btle use the same handling like for 802.15.4 extended
> address. Nevertheless is we can cleanup some handling then in generic
> iphc functionality.
Something to think about is there are networks which are not 15.4...
Including NFC, DECT/ULE, BACnet, and G.9959 (which uses 8-bit
short-addresses).
My gut is that DECT/ULE is going to take over :-)
> - In Lukasz Duda RFC for introducing stateful address compression, I
> saw some behaviour which such functionality is also useful. Currently
> we don't have a allocated space for a 6LoWPAN generic space which is
> assigned to a lowpan interface. When LL layers (BTLE, IEEE802154) calls
> iphc compress/decompress Lukasz had no change to access some room which
> is needed for storing the context information into a table. The
> workaround for this feature was to add allocate a static data room for
> the table and doing a lookup/match of netdev name. Which a generic
> 6lowpan private data room per each lowpan interface we can put this
> table according to the netdev private room, which means in short: no
> lookup is needed anymore, just dereferencing lowpan_priv.
yeah!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 481 bytes --]
next prev parent reply other threads:[~2015-08-01 7:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-31 12:38 [RFCv2 bluetooth-next 0/2] 6lowpan: introduce generic 6lowpan private data Alexander Aring
2015-07-31 12:38 ` [RFCv2 bluetooth-next 1/2] bluetooth: 6lowpan: change netdev_priv to lowpan_dev Alexander Aring
2015-08-04 13:11 ` Stefan Schmidt
2015-07-31 12:38 ` [RFCv2 bluetooth-next 2/2] 6lowpan: add generic 6lowpan netdev private data Alexander Aring
2015-08-04 13:11 ` Stefan Schmidt
2015-08-01 0:45 ` Michael Richardson [this message]
2015-08-03 9:44 ` iphc, rfc6553/6554 and 6lo ESC discussion Alexander Aring
2015-08-03 8:21 ` [RFCv2 bluetooth-next 0/2] 6lowpan: introduce generic 6lowpan private data Jukka Rissanen
2015-08-03 13:39 ` Alexander Aring
2015-08-03 13:54 ` Jukka Rissanen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6541.1438389931@sandelman.ca \
--to=mcr@sandelman.ca \
--cc=alex.aring@gmail.com \
--cc=linux-wpan@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.