Subject: [Roll] FW: ZigBee IP / rpl-08 questions.

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 7 Jun 2010 08:42:04 +0200

Dear WG

Mads asked us a few more questions on 08. Please find the discussion
below:

Pascal

From: Pascal Thubert (pthubert) 
Sent: Friday, June 04, 2010 6:08 PM
To: 'Westergreen Mads-MWEST2'
Subject: RE: ZigBee IP / rpl-08 questions.

Thanks a lot Mads. 

This is really appreciated. Please see below my early comments

1.       RPL draft 08  

There are some conflicts between RPL draft 08 and RPL metrics draft 06,
like the fact that option length of metric container is 1 byte in RPL
draft and 2 bytes in RPL metrics draft. We suppose that RPL metrics
document was not yet updated so we will go with the 1 byte length. What
is the correct length ?

[Pascal] One octet. This changed in 08 and is not yet reflected in the
metrics. The metrics is the reason why the lebth passed to 2 octets at
some point. They'll have to find a way to make stuff smaller J

2.       RPL draft 08 - Chapter 5.6.5 - Routing information

Although the Option Length field is a multiple of 1 byte, the length of
the prefix is 0, 8 or 16 bytes. The fact that the length of the prefix
is either 0, 8 or 16 is probably a copy-paste from the ND spec. As long
as the option length can be any number of bytes, we think there should
be no constraints on the length of the prefix included in this option.
Is this correct ?

[Pascal] This is correct. We can work that out by 09. I expect, though,
that in most cases the length with be 64. And alignment is still a good
thing though saving air space is another one.
 
3.     RPL draft 08 - Chapter 5.6.7 - RPL target 
Spec says that the RPL target option 'is used in DIO to identify a
resource that the root is trying to reach, but this option does not
appear in the list of options supported by DIO: chapter 5.3.3. How is
this option supposed to work in DIO ? There is no much written about
this. 
 
[Pascal] That is correct. I'll add some text. The option is valid in DIO
and it is used to trigger a (DAO) response from the target. A typical
scenario is a packet coming from the internet for a destination that
appears valid in the subnet but for which no DAO route is present at the
root. We'll have to rate limit such things to prevent DoS attacks. P2P
is another application by which the DAG is formed especially to reach
the target.
 
4.     RPL draft 08 - Chapter 5.6.7 - RPL target 

RPL target option appears in the list of supported options of DIS. When
RPL target option is described, the text does not say anything about
DIS. It only appears in DIO and DAO. What RPL target option should
contain when included in DIS and what is its purpose ?

[Pascal] That's probably why it's missing in DIO : ) Poor overloaded
editors are we? It might happen, though, that P2P want to use DIS as a
flooding mechanism, in which case they might want it.

5.       RPL draft 08 - Chapter 7.1.5

                    Is there any particular reason why a DAO is sent to
DODAG parents when it is initially created and only to DAO parents when
is 'forwarded' ?

[Pascal] what about propagated? In the usual terms that at least my
group use, write or send is about something really created by the sender
whereas forward applies to smoething that comes in and goes out, typical
for a router. When something is modified en route, I like the word
propagate rather than forward. In the case of a DOA, the control piece
is modified, so... Would you have a more preferred wording?

6.       RPL draft 08

What are the Target and Transit options of a DAO message supposed to
contain ? This question is related to another one: is a host device
supposed to send DAO messages?, because the discussion on the ZIP
reflector seems to indicate that host nodes are not able to send DAO
messages. Their parents will send DAO messages containing information
related to the hosts.

Does the target option contains information about the node sending the
DAO or about its children ? If it contains information about the node
sending the DAO it means that host nodes should be capable of sending
DAO messages to advertise their reachability.

[Pascal] At the moment there is no real concept of host in RPL. There
are nodes that do not send DIOs so they do not get to forward anything.
I've been trying to get 6LoWPANs to do the necessary things to enable
the 6LoWPAN registration to actually be injected in RPL. No such luck so
far, Erik is very firm on his positions.

                    What is the Transit option supposed to contain ?
Information about the node sending the DAO or about its parents ?

[Pascal] The transit option derives from Roger's work. Please find
attached his paper

                    Can you show an example of how the DAO messages sent
by nodes R1 and R2 should look like, giving the DODAG below and
considering that R2 should agregate the DAO messages received from both
R1 and R3?

                                                                LBR

                                                                  /

                                                                R2

                                                                /   \

                                                              R1     R3

                                                               /  \

                                                             H1   H2

RPL target refers to another node.

7.     RPL metrics draft 06  - 4.3.1.  The Link Quality Level
Reliability Metric
                                            4.4.1.  Link Color Object
Description
Both these options have the first 4 bits reserved. The length of the
option following these 4 bits is multiple of 8 bits. It would make more
sense if the reserved bits are extended to 8 because:
a)      The information following them will be easier to read/write, as
it will start on memory boundaries. Now it has to be shifted.
b)  The frame will be anyway have to be completed with 4 trailing bits
after the option

                    Any reason why the reserved bits cannot be extended
to 8 ?

[Pascal] I'll defer to my betters on this one J

Pascal