Subject: [Roll] Changes in p2p-rpl-06 over p2p-rpl-05

From: Mukul Goyal <[email-masked]>
Date: Thu, 19 Jan 2012 21:04:26 -0600 (CST)

Here is a summary of the changes in p2p-rpl-06 over p2p-rpl-05:

1. Introduced a new Mode of Operation - P2P Route Discovery Mode. DIOs in P2P-RPL MUST use this MOP. This ensures that RPL routers that do not understand P2P-RPL may only join as leaf nodes in the temporary DAGs used in P2P-RPL and do not inadvertently participate in a P2P-RPL route discovery.

2. Specified a default DODAG Configuration Option that comes in effect if the P2P mode DIO does not include an explicit one.

3. Replaced "Rem" field in P2P Route Discovery Option with "MaxRank/NH" field:

a) Rem field was used to indicate the number of empty slots in the Address vector. We thought that it would be possible for a node to simply modify a received DIO and transmit it. But, later on, we realized that since a DIO transmission is triggered by the Trickle timer firing, a router would have to always create a new DIO packet. Thus, there was no point any more in carrying empty slots in the Address vector. So, we replaced "Rem" field with a "MaxRank/NH" field.  

b) The "MaxRank/NH" field serves as the MaxRank when the P2P Route Discovery Option is carried inside a DIO. This field can be used to specify a constraint on the max rank that a router can have in the temporary DAG being used for a P2P-RPL route discovery. This field provides a way to specify a constraint without including a Metric Container. This field is particularly useful if OF0 (which does not use RPL routing metrics) is the objective function in use. Now, a P2P mode DIO, using OF0 as the OF, can avoid including a Metric Container (and thus save some bytes).

c) The "MaxRank/NH" field serves as the "NH(Next Hop)" field when the P2P Route Discovery Option is carried inside a DRO. This field indicates the index of the next hop address inside the Address vector.

4. Clarified that all routers participating in a P2P-RPL route discovery, including the origin and the target MUST join the temporary DAG being created for the purpose.

5. Changes to how "Consistent/Inconsistent" events are defined for Trickle operation in P2P-RPL:
a) New rule: The receipt of a P2P mode DIO from a parent in the temporary DAG
      is considered neither "consistent" nor "inconsistent" if it does
      not allow the router to advertise a better route than before.
In the absence of this rule, a router was suppressing its DIO because it received a "consistent" DIO from its parent. (The redundancy constant was 1). This was hampering the route discovery.

b) Clarified that the Imin parameter SHOULD be set taking in account the connectivity within the network. A small Imin value in a highly connected LLN could cause a DIO storm. This is because the first receipt of a DIO about a temporary DAG is treated as an inconsistent event and would cause the Trickle timer to reset to Imin.

c) Clarified that Imax should be set to a large value so that it is not a factor in the Trickle operation during the limited life of the temporary DAG.

d) Clarified that redundancy constant should be set to a value larger than 1 if packet loss rates are high. For moderate/low packet loss rates, the redundancy constant should be 1 to avoid unnecessary DIO generation.

6. Specified that a received P2P mode DIO must be dropped if the advertized rank is INFINITE_RANK (so any DIO advertized by a non-P2P-RPL router, that joined the temporary DAG as a leaf, would be dropped) or more than the MaxRank.

7. Added a section on interoperability with core RPL.

Thanks
Mukul

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 20 Jan 2012 11:44:21 +0100

Dear all,

as mentioned by Mukul in his previous mail, the changes from -05 to -06
were prompted by the results of the latest P2P-RPL interop. This interop
was carried out last month with INRIA's implementation against Sigma
Design's implementation, and a report is available here
http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf

Experiments with P2P-RPL have also taken place on the Senslab testbed
gathering boards based on MSP430 and 802.15.4 at 2.4GHz, see for instance
the experiments documented in
http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf

The INRIA implementation is available upon request.

Best regards,

Emmanuel

http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf

On Fri, Jan 20, 2012 at 4:05 AM, Mukul Goyal <[email-masked]> wrote:

> 1. Introduced a new Mode of Operation - P2P Route Discovery Mode. DIOs in
> P2P-RPL MUST use this MOP. This ensures that RPL routers that do not
> understand P2P-RPL may only join as leaf nodes in the temporary DAGs used
> in P2P-RPL and do not inadvertently participate in a P2P-RPL route
> discovery.
>
> 2. Specified a default DODAG Configuration Option that comes in effect if
> the P2P mode DIO does not include an explicit one.
>
> a) Rem field was used to indicate the number of empty slots in the Address
> vector. We thought that it would be possible for a node to simply modify a
> received DIO and transmit it. But, later on, we realized that since a DIO
> transmission is triggered by the Trickle timer firing, a router would have
> to always create a new DIO packet. Thus, there was no point any more in
> carrying empty slots in the Address vector. So, we replaced "Rem" field
> with a "MaxRank/NH" field.
>
> b) The "MaxRank/NH" field serves as the MaxRank when the P2P Route
> Discovery Option is carried inside a DIO. This field can be used to specify
> a constraint on the max rank that a router can have in the temporary DAG
> being used for a P2P-RPL route discovery. This field provides a way to
> specify a constraint without including a Metric Container. This field is
> particularly useful if OF0 (which does not use RPL routing metrics) is the
> objective function in use. Now, a P2P mode DIO, using OF0 as the OF, can
> avoid including a Metric Container (and thus save some bytes).
>
> c) The "MaxRank/NH" field serves as the "NH(Next Hop)" field when the P2P
> Route Discovery Option is carried inside a DRO. This field indicates the
> index of the next hop address inside the Address vector.
>
> 4. Clarified that all routers participating in a P2P-RPL route discovery,
> including the origin and the target MUST join the temporary DAG being
> created for the purpose.
>
> In the absence of this rule, a router was suppressing its DIO because it
> received a "consistent" DIO from its parent. (The redundancy constant was
> 1). This was hampering the route discovery.
>
> b) Clarified that the Imin parameter SHOULD be set taking in account the
> connectivity within the network. A small Imin value in a highly connected
> LLN could cause a DIO storm. This is because the first receipt of a DIO
> about a temporary DAG is treated as an inconsistent event and would cause
> the Trickle timer to reset to Imin.
>
> c) Clarified that Imax should be set to a large value so that it is not a
> factor in the Trickle operation during the limited life of the temporary
> DAG.
>
> d) Clarified that redundancy constant should be set to a value larger than
> 1 if packet loss rates are high. For moderate/low packet loss rates, the
> redundancy constant should be 1 to avoid unnecessary DIO generation.
>
> 6. Specified that a received P2P mode DIO must be dropped if the
> advertized rank is INFINITE_RANK (so any DIO advertized by a non-P2P-RPL
> router, that joined the temporary DAG as a leaf, would be dropped) or more
> than the MaxRank.
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>