iphc, rfc6553/6554 and 6lo ESC discussion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



{trimmed CC list}

Alexander Aring <alex.aring@xxxxxxxxx> 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: signature.asc
Description: PGP signature


[Index of Archives]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux