Bridging a lowpan interface

Bridging a lowpan interface

[David Palma]

Hi,

After shamefully trying it, I suppose it's not possible to add a lowpan interface to a bridge because it's not an ethernet segment.

However, I was wondering if this could/will be a possibility in the future?

If I understood correctly there was a discussion about the tun/tap driver that touched upon similar aspects, but I didn't get the conclusion.

The motivation for this question is to enable offloading/traffic redirection between 15.4 and .11 depending on certain conditions (e.g. energy and distance). I have accomplished this with changing routes and iptables but I was looking for an "SDN/OpenFlow-like" approach.

Thanks in advance,
--
David

Re: Bridging a lowpan interface

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]


David Palma <david.palma@ntnu.no> wrote:
    > After shamefully trying it, I suppose it's not possible to add a lowpan
    > interface to a bridge because it's not an ethernet segment.

    > However, I was wondering if this could/will be a possibility in the
    > future?

No, because 802.15.4 uses 8-byte EUI64 addresses, or 2-byte short addresses.

    > If I understood correctly there was a discussion about the tun/tap
    > driver that touched upon similar aspects, but I didn't get the
    > conclusion.

    > The motivation for this question is to enable offloading/traffic
    > redirection between 15.4 and .11 depending on certain conditions
    > (e.g. energy and distance). I have accomplished this with changing
    > routes and iptables but I was looking for an "SDN/OpenFlow-like"
    > approach.

Stupid Layer-2 tricks are a bad idea here.
Use smart layer-3 techniques instead: routing.

Assuming that both of your devices have 15.4 and .11 interfaces, then put
them into seperate subnets, and then distribute /128 addresses to your end
systems, and use a dynamic routing protocol to announce things.

Choices would include: RPL (see my unstrung.sandelman.ca, and others),
BABEL, OSPFv3.

Before you complain about overhead of that, you need to go read the source
code for the bridging code that includes {R,M,}STP.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Bridging a lowpan interface

[David Palma]

Hi Michael,

Thanks for sharing your knowledge and views.

I'm all for routing and starting with RPL is fine. However, the idea was also to enable traffic differentiation based on flows (the SDN part), without breaking them, and not only based on IP addresses. That's why I mentioned that I used routing and ip6tables.

I was just wondering if there was a way of integrating lowpan interfaces with the other typical solutions.

Cheers,
--
David

> On 10 Nov 2017, at 18:46, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> David Palma <david.palma@ntnu.no> wrote:
>> After shamefully trying it, I suppose it's not possible to add a lowpan
>> interface to a bridge because it's not an ethernet segment.
> 
>> However, I was wondering if this could/will be a possibility in the
>> future?
> 
> No, because 802.15.4 uses 8-byte EUI64 addresses, or 2-byte short addresses.
> 
>> If I understood correctly there was a discussion about the tun/tap
>> driver that touched upon similar aspects, but I didn't get the
>> conclusion.
> 
>> The motivation for this question is to enable offloading/traffic
>> redirection between 15.4 and .11 depending on certain conditions
>> (e.g. energy and distance). I have accomplished this with changing
>> routes and iptables but I was looking for an "SDN/OpenFlow-like"
>> approach.
> 
> Stupid Layer-2 tricks are a bad idea here.
> Use smart layer-3 techniques instead: routing.
> 
> Assuming that both of your devices have 15.4 and .11 interfaces, then put
> them into seperate subnets, and then distribute /128 addresses to your end
> systems, and use a dynamic routing protocol to announce things.
> 
> Choices would include: RPL (see my unstrung.sandelman.ca, and others),
> BABEL, OSPFv3.
> 
> Before you complain about overhead of that, you need to go read the source
> code for the bridging code that includes {R,M,}STP.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 

Re: Bridging a lowpan interface

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]


David Palma <david.palma@ntnu.no> wrote:
    > I'm all for routing and starting with RPL is fine. However, the idea
    > was also to enable traffic differentiation based on flows (the SDN
    > part), without breaking them, and not only based on IP
    > addresses. That's why I mentioned that I used routing and ip6tables.

I don't understand what the problem is.
What would you do with bridged interfaces in an SDN?
What kind of breaking are you speaking of?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Bridging a lowpan interface

[David Palma]

> On 11 Nov 2017, at 19:53, Michael Richardson <mcr@sandelman.ca> wrote:
> 
> 
> David Palma <david.palma@ntnu.no> wrote:
>> I'm all for routing and starting with RPL is fine. However, the idea
>> was also to enable traffic differentiation based on flows (the SDN
>> part), without breaking them, and not only based on IP
>> addresses. That's why I mentioned that I used routing and ip6tables.
> 
> I don't understand what the problem is.
> What would you do with bridged interfaces in an SDN?

For example, if you use Open vSwitch for the SDN part, you add an interface to a bridge and manage flows from there.

> What kind of breaking are you speaking of?

By breaking I mean, for example:
- establish a CoAP transaction with DTLS through one interface/network (e.g. .11, fd03::120)
- redirect the traffic to another interface/network (e.g. 15.4, fe80::ff:fe00:beef)
- a new transaction will be created on the CoAP server, it will expect a DTLS handshake, it will timeout because the client is not expecting a new transaction.

I guess this could happen in other scenarios too, but I could be wrong.

My approach to this is re-writing the sources and destinations at the edges, per flow (using Ip6tables for the time being).

What I thought was that if the 8/2 byte addresses were converted to 6 byte addresses one could just use Open vSwitch/bridges/etc.

--
David

http://dpalma.eu

> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 

Re: Bridging a lowpan interface

[Alexander Aring]

Hi,

On Sat, Nov 11, 2017 at 5:59 PM, David Palma <david.palma@ntnu.no> wrote:
>
>> On 11 Nov 2017, at 19:53, Michael Richardson <mcr@sandelman.ca> wrote:
>>
>>
>> David Palma <david.palma@ntnu.no> wrote:
>>> I'm all for routing and starting with RPL is fine. However, the idea
>>> was also to enable traffic differentiation based on flows (the SDN
>>> part), without breaking them, and not only based on IP
>>> addresses. That's why I mentioned that I used routing and ip6tables.
>>
>> I don't understand what the problem is.
>> What would you do with bridged interfaces in an SDN?
>
> For example, if you use Open vSwitch for the SDN part, you add an interface to a bridge and manage flows from there.
>
>> What kind of breaking are you speaking of?
>
> By breaking I mean, for example:
> - establish a CoAP transaction with DTLS through one interface/network (e.g. .11, fd03::120)

Check out ndisc proxy for IPv6.

There is no automatically handling for that inside the kernel (please
send-patches, somebody wanted already such feature). What I mean for
IPv4 yes, but for IPv6 you need a daemon like [0].

- Alex

[0] https://github.com/DanielAdolfsson/ndppd

Re: Bridging a lowpan interface

[Alexander Aring]

Hi,

On Sat, Nov 11, 2017 at 7:06 PM, Alexander Aring <aring@mojatatu.com> wrote:
> Hi,
>
> On Sat, Nov 11, 2017 at 5:59 PM, David Palma <david.palma@ntnu.no> wrote:
>>
>>> On 11 Nov 2017, at 19:53, Michael Richardson <mcr@sandelman.ca> wrote:
>>>
>>>
>>> David Palma <david.palma@ntnu.no> wrote:
>>>> I'm all for routing and starting with RPL is fine. However, the idea
>>>> was also to enable traffic differentiation based on flows (the SDN
>>>> part), without breaking them, and not only based on IP
>>>> addresses. That's why I mentioned that I used routing and ip6tables.
>>>
>>> I don't understand what the problem is.
>>> What would you do with bridged interfaces in an SDN?
>>
>> For example, if you use Open vSwitch for the SDN part, you add an interface to a bridge and manage flows from there.
>>
>>> What kind of breaking are you speaking of?
>>
>> By breaking I mean, for example:
>> - establish a CoAP transaction with DTLS through one interface/network (e.g. .11, fd03::120)
>
> Check out ndisc proxy for IPv6.
>
> There is no automatically handling for that inside the kernel (please
> send-patches, somebody wanted already such feature). What I mean for
> IPv4 yes, but for IPv6 you need a daemon like [0].
>

btw: we need short address handling for this... because 2 types of mac
addresses is not really supported by net core api and currently we
handle this _very_ 802.15.4 interface specific. Just you know about...
that you run into issues with that (When you not solve it). Patches
are welcome always!

- Alex

Re: Bridging a lowpan interface

[David Palma]

Hi Alex,

Thanks for the pointers, will look into this further.

Cheers,
--
David

> On 12 Nov 2017, at 01:09, Alexander Aring <aring@mojatatu.com> wrote:
> 
> Hi,
> 
> On Sat, Nov 11, 2017 at 7:06 PM, Alexander Aring <aring@mojatatu.com> wrote:
>> Hi,
>> 
>> On Sat, Nov 11, 2017 at 5:59 PM, David Palma <david.palma@ntnu.no> wrote:
>>> 
>>>> On 11 Nov 2017, at 19:53, Michael Richardson <mcr@sandelman.ca> wrote:
>>>> 
>>>> 
>>>> David Palma <david.palma@ntnu.no> wrote:
>>>>> I'm all for routing and starting with RPL is fine. However, the idea
>>>>> was also to enable traffic differentiation based on flows (the SDN
>>>>> part), without breaking them, and not only based on IP
>>>>> addresses. That's why I mentioned that I used routing and ip6tables.
>>>> 
>>>> I don't understand what the problem is.
>>>> What would you do with bridged interfaces in an SDN?
>>> 
>>> For example, if you use Open vSwitch for the SDN part, you add an interface to a bridge and manage flows from there.
>>> 
>>>> What kind of breaking are you speaking of?
>>> 
>>> By breaking I mean, for example:
>>> - establish a CoAP transaction with DTLS through one interface/network (e.g. .11, fd03::120)
>> 
>> Check out ndisc proxy for IPv6.
>> 
>> There is no automatically handling for that inside the kernel (please
>> send-patches, somebody wanted already such feature). What I mean for
>> IPv4 yes, but for IPv6 you need a daemon like [0].
>> 
> 
> btw: we need short address handling for this... because 2 types of mac
> addresses is not really supported by net core api and currently we
> handle this _very_ 802.15.4 interface specific. Just you know about...
> that you run into issues with that (When you not solve it). Patches
> are welcome always!
> 
> - Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html