Subject: [Roll] host only nodes in RPL

From: Michael Richardson <[email-masked]>
Date: Thu, 06 May 2010 11:37:04 -0400

Pascal and a few other people asked about host only systems in an RPL
network.

Consider an industrial application.  There is some piece of machinery.
I'm going to pick some cool hydralic forklift.  Maybe it's a robot (no
operator).   It has several dozen sensors and actuators, linked together
by some kind of fibre-optic LAN because of noise issues.  (Maybe this new
Intel optical connect).  Those sensors are going to be interogated by a
management system.

There are two network architectures I can see:
      1) the forklift has a single interface node, it runs RPL
         on the wireless interface, and normal IPv6 on the internal
         sensor network.  Either routing(%) or application-layer gateway
         occurs.

      2) the forklift has one or more interface nodes, it runs RPL
         on one interface, and implements (layer-2) a network bridge to
         the other interface.

In case 1, we can use all sorts of network routing protocols to make the
subnet for the forklift reachable on the RPL network.  A grounded RPL
uplink node can do things as simple as:
       route add -net 2001:fork:lift:gate::/64 2001:fork:lift::host

In case 2, we don't do this.  There are many reasons perhaps why we
might not do this --- perhaps the sensors in the forklift must interact
a lot with a lot of devices that are nearby.   

In case 2, do those nodes speak RPL, or does the edge router(s) do RA/RS?

(I don't have an answer.  I think that layer-2 bridging like case 2 is
IPv4 think, and routing is a better choice)

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 May 2010 20:02:07 +0200

Forklift RoLLing around

     ____|
    /    |
   |-----|____
    O   O

>           sensor network.  Either routing(%) or application-layer gateway

(exception - stepping back from the assumption RPL must be run here)

If I were presented to such a deployment, and knowing the forklift moves
within a limited area (a hangar?) then I'd immediately think the egress
interface of that forklift is WiFi - a single subnet - no change in IP
address nor routes.

If the area is larger (maybe a few ARs each 50meter range, with less 
than 10 subnets) then I would first try an existing routing protocol 
like OSPF or simpler RIP on the MR, but not on the devices on the forklift.

If even larger area (route updates provoking too much "churn" - numerous 
route updates, large routing tables) then use Mobile IP tunnels and NEMO 
extensions for moving networks, still on that MR, still not on the devices.

> a lot with a lot of devices that are nearby.

YEs - and the first one is the big red round button ("mushroom"?) which
stops everything. Every automated device has such a "mushroom" triggered
by humans in an emergency, its on/off state is of paramount importance
to the control room.

> IPv4 think, and routing is a better choice)

Don't have the nodes on the forklift talk RPL, no need, no requirement.
They're simple and small, they'd hardly host an IP stack in the first
place. Have something special on the forklift's bigger Mobile Router(?)
do special things.

Alex

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 May 2010 12:04:37 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    >> 2) the forklift has one or more interface nodes, it runs RPL on
    >> one interface, and implements (layer-2) a network bridge to the
    >> other interface.
    >> 
    >> In case 1, we can use all sorts of network routing protocols to
    >> make the subnet for the forklift reachable on the RPL network.  A
    >> grounded RPL uplink node can do things as simple as: route add
    >> -net 2001:fork:lift:gate::/64 2001:fork:lift::host
    >> 
    >> In case 2, we don't do this.  There are many reasons perhaps why
    >> we might not do this --- perhaps the sensors in the forklift must
    >> interact a lot with a lot of devices that are nearby.

    Alexandru> YEs - and the first one is the big red round button
    Alexandru> ("mushroom"?) which stops everything. Every automated
    Alexandru> device has such a "mushroom" triggered by humans in an
    Alexandru> emergency, its on/off state is of paramount importance to
    Alexandru> the control room.

    >> (I don't have an answer.  I think that layer-2 bridging like case
    >> 2 is IPv4 think, and routing is a better choice)

    Alexandru> Don't have the nodes on the forklift talk RPL, no need,
    Alexandru> no requirement.  They're simple and small, they'd hardly
    Alexandru> host an IP stack in the first place. Have something
    Alexandru> special on the forklift's bigger Mobile Router(?)  do
    Alexandru> special things.

  So, I agree that this is better.
  I am assuming that the sensors host an IP stack, because if they don't, then
the example becomes moot.

  Given that they host an IP stack, if the forklift has a mobile router
on board, then the sensors do not need to speak RPL.  The mobile router
can speak RPL on one interface, and then do RA/RS with the nodes on the
other. 
  What this amounts to is that there are few reasons to have "host-only"
nodes in RPL.  There may many "leaf-nodes" in an RPL network, and they
need to speak RPL because they don't know which "router-node" they are
going to connect to, while on the forklift, there sensors are connected
via wires, etc.

- --

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 May 2010 18:17:37 +0200

Le 07/05/2010 18:04, Michael Richardson a écrit :
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
>
>>>>>> "Alexandru" == Alexandru
>>>>>> Petrescu<[email-masked]>  writes:
> Alexandru>  emergency, its on/off state is of paramount importance
> to Alexandru>  the control room.
>
>>> (I don't have an answer.  I think that layer-2 bridging like
>>> case 2 is IPv4 think, and routing is a better choice)
>
> So, I agree that this is better. I am assuming that the sensors host
>  an IP stack, because if they don't, then the example becomes moot.

I agree.

> Given that they host an IP stack, if the forklift has a mobile
> router on board, then the sensors do not need to speak RPL.

I agree: the sensors on the forklift do not need to speak RPL.

> The mobile router can speak RPL on one interface, and then do RA/RS
> with the nodes on the other.

I agree 100% with the second part - onboard MR speaks RA/RS with the
nodes on the foklift.  What MR runs on its egress interface depends on
many other factors.

> What this amounts to is that there are few reasons to have
> "host-only" nodes in RPL.

Ok.  But one must be sure that a node running RPL (the MR?) also runs
RS/RA towards a host-only.  You may want a Router which runs both RPL
and RS/RA.

Considering RPL only between RPL nodes without caring about hosts-only
breaks many things - it's not connected to the Internet.

> There may many "leaf-nodes" in an RPL network, and they need to
> speak RPL because they don't know which "router-node"

I disagree.  An RPL network should support hosts-only connecting to it,
and all connected to the Internet.

Actually it's the leaf node host-only which should dictate what happens
here.  Not RPL.  And a host-only leafnode runs RS/RA first.  If it has
spare memory then runs additional things like RPL.

IMHO.

Alex

> they are going to connect to, while on the forklift, there sensors
> are connected via wires, etc.
>
> - -- ]       He who is tired of Weird Al is tired of life! |
> firewalls  [ ]   Michael Richardson, Sandelman Software Works,
> Ottawa, ON    |net architect[ ] [email-masked]
> http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch
>  the video<http://www.youtube.com/watch?v=kzx1ycLXQSE> then sign the
>  petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9
> (GNU/Linux) Comment: Finger me for keys
>
> iQEVAwUBS+Q6E4CLcPvd0N1lAQKWhAf+Jjype+icX4CGGw4HfxuAMws1m2UQdZRb
> 6IhqSTlbEEs5XUG2Wbh9a8ikKAqgDTibkzYBs3lMMRTs8JKTd6Fq8zRbB9IVy8Qy
> RJxTlRU6oQxIDBCajOvHmtbPCc2y3XOrxBfrja80cw5lNYpubab+WLb6bmJ2KJ7V
> NJ0YOdVTAHkFxZ4S4AM8LorsssAtxrsX/kOqSVbU7Hrg+VeagRFMmzZeRwTsny+t
> OlW9OfOP8KxxEhgv6PA4+kQnho/VVPcSj/c8isyGjCHVbMDuWetgiDC5BSLvzytb
> 4JNB5LOI7zzhoU2UKXEthVb2JGYfTJ6nB6ounBwNmHhxm0DqJ6pl2Q== =dzQa
> -----END PGP SIGNATURE-----
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 May 2010 16:01:20 -0400

>> So, I agree that this is better. I am assuming that the sensors
    >> host an IP stack, because if they don't, then the example becomes
    >> moot.

    Alexandru> I agree.

    >> router on board, then the sensors do not need to speak RPL.

    Alexandru> I agree: the sensors on the forklift do not need to speak
    Alexandru> RPL.

    >> The mobile router can speak RPL on one interface, and then do
    >> RA/RS with the nodes on the other.

    Alexandru> I agree 100% with the second part - onboard MR speaks
    Alexandru> RA/RS with the nodes on the foklift.  What MR runs on its
    Alexandru> egress interface depends on many other factors.

okay, but if it isn't speaking RPL, then it's out of scope.

    >> "host-only" nodes in RPL.

    Alexandru> Ok.  But one must be sure that a node running RPL (the
    Alexandru> MR?) also runs RS/RA towards a host-only.  You may want a
    Alexandru> Router which runs both RPL and RS/RA.

    Alexandru> Considering RPL only between RPL nodes without caring
    Alexandru> about hosts-only breaks many things - it's not connected
    Alexandru> to the Internet.

huh? Can you explain what you mean?

    >> speak RPL because they don't know which "router-node"

    Alexandru> I disagree.  An RPL network should support hosts-only
    Alexandru> connecting to it, and all connected to the Internet.

    Alexandru> Actually it's the leaf node host-only which should
    Alexandru> dictate what happens here.  Not RPL.  And a host-only
    Alexandru> leafnode runs RS/RA first.  If it has spare memory then
    Alexandru> runs additional things like RPL.

okay, I'd like to know what node replies to the RS for the host-only.

- --

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 May 2010 22:26:07 +0200

[I wish I had gnus to cite replies as you do...]

Le 07/05/2010 22:01, Michael Richardson a écrit :
>>> host an IP stack, because if they don't, then the example
>>> becomes moot.
>
> Alexandru>  I agree.
>
> Alexandru>  I agree: the sensors on the forklift do not need to
> speak Alexandru>  RPL.
>
> Alexandru>  RA/RS with the nodes on the foklift.  What MR runs on
> its Alexandru>  egress interface depends on many other factors.
>

I agree the forklift router has at least two interfaces: one presumably
RPL and the other surely RS/RA non-RPL.  Forklift in hangar is a good case.

(I believe the scenario is to have a forklift router which has at least
two interfaces - one presumably running RPL.  And the other interface,
the one important to this discussion - the one _not_ running RPL in any
case, just doing RS/RA to the mushroom button.)

> Alexandru>  MR?) also runs RS/RA towards a host-only.  You may want
> a Alexandru>  Router which runs both RPL and RS/RA.
>

An RPL network to which my non-RPL PDA can't connect?  Such a network is
broken - don't use it.

I mean that if one builds an RPL network incapable of hosting non-RPL
host-only leaf nodes then one does this for nothing, i.e. disconnected
from the Internet.  One could as well do RPL somewhere else than IETF.

Try to connect a non-RPL host to it and its ND breaks, base header
fields are badly understood and so on - no Internet.

> okay, I'd like to know what node replies to the RS for the

If the RPL Router sends a non-RPL RS on the interface towards a non-RPL
node then the node will know what to reply, according to the Neighbor
Discovery RFCs.

I meant to say that the RPL router should be able to act as a non-RPL
RS/RA on its interface on which a non-RPL host will connect.  Otherwise
RPL router is useless.  In this sense, the RPL Router should follow what
the non-RPL host needs.

Alex

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 May 2010 09:28:13 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    Alexandru> [I wish I had gnus to cite replies as you do...]

(NTEmacs runs on your platform, and thunderbird supports external
editors..)

    mcr> What this amounts to is that there are few reasons to have
    mcr> "host-only" nodes in RPL.

    Alexandru> Ok.  But one must be sure that a node running RPL (the
    Alexandru> MR?) also runs RS/RA towards a host-only.  You may want
    Alexandru> a Router which runs both RPL and RS/RA.

    >> huh? Can you explain what you mean?

    Alexandru> An RPL network to which my non-RPL PDA can't connect?
    Alexandru> Such a network is broken - don't use it.

    Alexandru> I mean that if one builds an RPL network incapable of
    Alexandru> hosting non-RPL host-only leaf nodes then one does this
    Alexandru> for nothing, i.e. disconnected from the Internet.  One
    Alexandru> could as well do RPL somewhere else than IETF.

I think I've having a problem with the words here.

For me, a "host-only" node is one that does not speak RPL.

Versus, a "leaf" node is one that does speak RPL, but doesn't relay
        packets. Either due to capability or design, or because there
        are no nodes which have picked it as a parent.

So a host-only leaf node is a contradiction to me.

A host-only node talks RS/RA to something, such as in the forklift
example, the "Mobile Router", and likely does it on a different layer-2.

A leaf-node is part of the RPL, it's just at the bottom.
Not-storing nodes in a storing network, for instance, would be forced to
be leaf-only.

So again, what router is answering their RS/RA messages?

    >> okay, I'd like to know what node replies to the RS for the

    Alexandru> If the RPL Router sends a non-RPL RS on the interface
    Alexandru> towards a non-RPL node then the node will know what to
    Alexandru> reply, according to the Neighbor Discovery RFCs.

    Alexandru> I meant to say that the RPL router should be able to act
    Alexandru> as a non-RPL RS/RA on its interface on which a non-RPL
    Alexandru> host will connect.  Otherwise RPL router is useless.  In
    Alexandru> this sense, the RPL Router should follow what the non-RPL
    Alexandru> host needs.

Yes, on another interface, which is configured in a non-RPL way.

Perhaps a diagram is in order.

- --

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 May 2010 14:29:52 +0200

Le 10/05/2010 15:28, Michael Richardson a écrit :
[...]
> So a host-only leaf node is a contradiction to me.

I see what you mean.  To me it is strange to call a leaf-node something 
which is not an end (in the TCP sense of "end-to-end"), i.e. something 
which is not a Host.

You (this terminology definers) call it Leaf as if everything ended 
there.  They forget the goal of this is to have routes for applications 
running on Hosts.  RPL for the sake of RPL is to of much use.

> example, the "Mobile Router", and likely does it on a different layer-2.

WEll no.  The forklift Mobile Router could have Bluetooth on an 
interface and another Bluetooth on another interface, and route between 
the two.

> A leaf-node is part of the RPL, it's just at the bottom.

... as if everything ended there - where are the applications running?

> Not-storing nodes in a storing network, for instance, would be forced to

RPL would run always on non-storing networks, I don't see the 
"store-and-forward" aspect in RPL, I think it's not intended so.

> So again, what router is answering their RS/RA messages?

Hmmm, I think the forklift RPL router must answer an non-RPL RS sent by 
a Host to it.  If it doesn't then it's useless.

> Yes, on another interface, which is configured in a non-RPL way.

Well yes.  So it is a Router which has an RPL interface and another 
non-RPL interface.  Remark that RPL routers should also be able to run 
non-RPL RS/RA on their RPL interfaces, otherwise non-RPL Hosts 
connecting to their RPL interfaces will not be able to talk to them.

> Perhaps a diagram is in order.

Hm.

Alex

>     Kyoto Plus: watch the video<http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	then sign the petition.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBS+gJ64CLcPvd0N1lAQI7dgf9F9SDbahoM8kI3lNwP1GcYsOG1XLhIb8m
> 50gS1HUbU6NdHivV0ks7S8eN8wjKOjNAObAR473ZZQH3mKrYDb7JAEAENHxcPjL4
> 5pefdx871ZudEnIZUsGioWvU2gh2SymbrmpgFsEdssXSisJoxgjqhNJ0M+uPkwmQ
> 34cHD/LR2+DRqmfKH2Gkn0Irlyl56EysRx4rbKkG7dIgqQfaBTYlS+Tg6KGB19l3
> Qpzendf1CGWkvT1DJVdzWqcinPATqjeNNCwcloePxymMDi6D72YKGIeTyiqOT8Tk
> Ru6YCRjmenxNXQESty+KMzazgeXNj/F1+4totG/fHvyMIXetPExGcg==
> =BB4o