Subject: [6lowpan] Lowpan Backbone Router draft

From: Anthony Schoofs <[email-masked]>
Date: Tue, 8 Apr 2008 10:05:10 +0200

Hi Pascal,

I went through your draft about the concept of a Backbone Router to help
large-scale networks deployments. I have a few comments about the draft, I
put them below:

In Figure 1 you drew one single gateway that connects the backbone router
to the plant network. You do not refer to it later in the document. Is it
something application specific, a requirement for the backbone router
approach or a consequence to it? For any case, I would mention it or remove
it from the figure.

In Section 6.1, you wrote that Bacbone Routers announce themselves using
RAs that are broadcasted. Maybe you could see whether the solution proposed
in draft-chakrabarti-6lowpan-ipv6-nd-04.txt section 6.2 can help avoid
sending many broadcast messages. As a resume, they suggest:
" .. the PAN co-ordinator aka IPv6 router sends periodic RA to the
co-ordinators in its PAN by sending unicast messages to each of them...
Each co-ordinator can act as proxy IPv6 router advertiser and they can
broadcast the RA on behalf of the IPv6-router in their own domain
periodically.."

In Section 6.4, you mention that the target link-layer address is that of
the destination if a shorcut is possible over the Lowpan. Do you plan to
specify the mechanism that will tell the nodes if they have to go through
the Backbone Router or not for a communication? Shortly, how do the nodes
know if a shorcut is possible and better than the backbone route? Is it out
of scope of this document?

There are various benefits of the Backbone router approach that may be
mentionned in the document. If you let backbone routers take care of the
routing for the nodes for instance, it may result in only unicast packets
within the different lowpans (towards and from the backbone router), which
will have as consequences
1) less interferences (less packets in the air due to routes that are known
from the backbone router to the destination node and due to the shorcut
that the backbone may offer compared to long multihop communications)
2) less broadcast packets
3) reduced memory requisite for routing tables on the nodes
4) longer battery life for the sensor nodes.
This could be made more visible in the document.

Best regards,
Anthony

--
Anthony Schoofs
Research Scientist, Flexnod project, CCS Group
Philips Research WY 7-038
High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands
Tel: (+31) 40 27 49 654
Email: [email-masked]

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Apr 2008 11:05:15 +0200

Hi Anthony:

Thanks a whole bunch for this review. Let me please respond inline

[Anthony]
I went through your draft about the concept of a Backbone Router to help
large-scale networks 
deployments. I have a few comments about the draft, I put them below:

In Figure 1 you drew one single gateway that connects the backbone
router to the plant network. You do not refer to it later in the
document. Is it something application specific, a requirement for the
backbone router approach or a consequence to it? For any case, I would
mention it or remove it from the figure.

[Pascal]
The figure depicts the current ISA100.11a reference model. I need to add
words that this model applies to many situations in industrial, home and
building automation, but certainly not all and that the gateway could
become a firewall or a simple router depending on the use case. In the
same fashion, the plant network can be the building control network, the
Service Provider network or even the Internet.

[Anthony]
In Section 6.1, you wrote that Bacbone Routers announce themselves using
RAs that are broadcasted. Maybe you could see whether the solution
proposed in draft-chakrabarti-6lowpan-ipv6-nd-04.txt section 6.2 can
help avoid sending many broadcast messages. As a resume, they suggest:
" .. the PAN co-ordinator aka IPv6 router sends periodic RA to the
co-ordinators in its PAN by sending unicast messages to each of them...
Each co-ordinator can act as proxy IPv6 router advertiser and they can
broadcast the RA on behalf of the IPv6-router in their own domain
periodically.."

[Pascal] 
Very right. 

The focus of this doc is to illustrate the white board approach and the
use of proxy ND over the backbone to scale up the LoWPAN. If the group
agrees that this is the direction then we can dig further and merging
with draft-chakrabarti would be an excellent idea. It is clear to me
that my Draft 00 falls short in a number of occasions which were not the
focus at the time.

- registration mechanism. DHCP formats make more sense than NS/NA that I
used. I asked Benoit Lourdelet to join as a coauthor to rework that. I
also got comments that a totally new format could be welcome, along the
lines of RFC 3775 Binding Update (though the BU as it stands is not fit
for the job) but for the time being I'd rather stick to DHCPv6 and see
the feedback from the group.

- NS lookup. There can be 2 ways, proactive and reactive. My draft
reflects proactive using unicast NS/NA with the white board (and it will
be based on DHCP RFC 5007 in the next release). It's good because it
woorks for any type of address, link local, unique local and global.
draft-chakrabarti proposes a reactive version where the backbone router
does the lookup for you with an implicit request that comes with the
packet to be forwarded. This saves the NS/NA flow but causes all packets
to flow via the BbR. The route optimization with the PAN can still
happen under the BbR control using redirects. I think we need both
approaches make sense and are needed; that's a good reason to merge the
drafts.

- RA (as you point out), and that includes for me advertising the DHCP
relay and white board capabilities so we skip the SOLLICIT flow that is
normally multicast but makes little sense here. I had nothing much to
add to the excellent work that is already there in draft-chakrabarti;
that's another good reason to merge the drafts.

[Anthony]
In Section 6.4, you mention that the target link-layer address is that
of the destination if a shorcut is possible over the Lowpan. Do you plan
to specify the mechanism that will tell the nodes if they have to go
through the Backbone Router or not for a communication? Shortly, how do
the nodes know if a shorcut is possible and better than the backbone
route? Is it out of scope of this document?

[Pascal]

My draft does not say haw the routing is done (mesh under or route over)
and I do not think there is an assumption about it. What it does is a
proactive unicast NS/NA that results in the 16 or 64bit address of the
next hop. If the next hop is outside of the PAN then you get something
that leads to the BbR. If the nect hop is inside the PAN (the
destination) then you should get the address of that destination and you
packet will get there directly. 

There is a complexity involved in the case where multiple BbRs serve the
same PAN. They have to figure that the route inside the PAN exists and
is shorter than the route outside via the BbRs and the backbone. I think
that there's a point where we'll be needing ROLL to sort out these
issues. My draft does not cover that and expects a single BbR, hot
standby BbRs, or a default policy for inside routes vs. outside routes.

[Anthony]

There are various benefits of the Backbone router approach that may be
mentionned in the document. If you let backbone routers take care of the
routing for the nodes for instance, it may result in only unicast
packets within the different lowpans (towards and from the backbone
router), which will have as consequences 
1) less interferences (less packets in the air due to routes that are
known from the backbone router to the destination node and due to the
shorcut that the backbone may offer compared to long multihop
communications) 
2) less broadcast packets 
3) reduced memory requisite for routing tables on the nodes 
4) longer battery life for the sensor nodes. 
This could be made more visible in the document.

[Pascal]
This should be made more visible in the document, and though the
document does not specify how offline routing can be done there is a
common spirit between the two and the benefits are similar. 

Note that both ISA100.11a and WiHART assume offline routing and that it
will certainly be an option to consider for ROLL. I trust that most
readers figured that those benefits apply to this draft already but it
certainly does not hurt to add a small section about benefits that we
expect from avoiding multicast and using the backbone as we do.

Thanks a bunch Anthony,

Pascal

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Apr 2008 14:25:29 -0700

Pascal Thubert (pthubert) wrote:

> use of proxy ND over the backbone to scale up the LoWPAN.

Pascal,

can you explain how using proxy ND makes things more efficient and/or 
more robust? Mapping the IPv6-all routers multicast address to a 
functional/anycast Lowpan address combined with VRRP seems to be 
sufficient to handle finding the routers including failover. Thus to me 
ND proxy seems like nothing but a distraction here.

> If the group

But you'd also need to handle a distributed whiteboard so you whiteboard 
doesn't become a SPoF. And if you use (unicast) NS as the way to do 
lookups from the whiteboard, then there is a strong reason to co-locate 
the whiteboard with the entity handling the NS; it might make sense to 
have a common protocol for registrations and lookups. Neither current ND 
nor current DHCP is a good fit for a combined registration and lookup 
protocol. Furthermore, if we want to add key distribution to the fix, 
then the requirements on the registration and lookup protocol (or 
protocols) changes.

> to flow via the BbR. 

Not necessarily. The router can unicast a redirect which tells host A 
which L2 address to use to reach host B directly.

Whether or not to do that might depend on the stability of the L2 
topology. If it is more stable to always go to and from the router than 
that might make more sense than finding a direct path that might be less 
stable.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Apr 2008 11:19:18 +0200

>functional/anycast LoWPAN address combined with VRRP seems to be

[Pascal] Hi Erik:

Thanks a bunch for helping here.

The main requirement that the draft is addressing is scaling the LowPAN
by merging multiple PANs over a backbone. This requirement comes from
the industrial space but the topology appears in multiple other use
cases, in building and home automation for instance. 

One specific aspect of this requirement is that a node can move from a
LoWPAN to another LoWPAN attached to the same backbone link and keep its
(set of) address(es). In particular it should be possible to own a link
local address, connect to any LoWPAN or to the backbone with that
address, and ping any other link local address connected to any LoWPAN
or to the backbone with that address.

This is where the proxy ND comes from. Very close to RFC 3775 (MIPv6)
using the backbone link similarly to a home link, but a different flavor
of registration because there is no CoA and no need for tunnel. ND on
the backbone enables the cohabitation of MIP and BbR protocols so that a
LoWPAN node can move locally or far far away. 

Once you have a registry you can use it for the purpose of DAD and NS
lookup. Thus the discussion on proactive white board. This does not
prevent the use of reactive white boarding through the registry or any
other Backbone router so forwarding could be maintained upon registry
failure if we make the necessary efforts in the protocol.

As you see, the proxy ND function is the core of the draft, and the
white board is a benefit. Yes, we do need to handle RAs efficiently and
we do need a redundancy technique for the BbRs. 

>then the requirements on the registration and lookup protocol (or

[Pascal] I agree (almost) all the way through. I'd add that:

- WRT SPoF: Distributing the white board is similar to distributing the
HAs in MIP. They collectively own the table of all the registered
addresses on the "home" backbone link. If one dies, there is an
interruption of service for the nodes it serves till they register
somewhere else. I've been trying to introduce a secondary registration
to enable hot stand by, bicasting and uninterrupted service but I'm not
sure it's a such a good idea. Maybe it's better to leave the redundancy
up to the vendors as we do with MIP.

- WRT DHCP relevancy:  I talked to DHCP specialists in cisco and they
felt that DHCP could do stateful registrations and lookups nicely using
RFC 5007 for the lookup. I plan to publish a draft 01 with text from
Benoit that proposes just that as a base for the discussion. Certainly
I'm completely open to a new protocol if your approach prevails within
the group. I just found that DHCP was way closer than MIP to the
registration solution that we need and a good starting point. DHCP also
enables the BbR to compute a SeND CGA address on behalf of the mote that
might not want to spend half its battery in the process. 

Pascal