Using:RPL

Navigation: Home | Scenarios | Installing | Using | Future

Using:Setup | Using:Troubleshooting | Using:Shell | Using:Sensors | Using:Actuation | Using:SLIP | Using:Webserver | Using:HTTP | Using:RPL

Table of Contents Goal References Preparing Building Running Sink, alone Sender Joins Sink, after sender arrives

Goal

Let's dig a little deeper into RPL. Thanks to the exhaustive RPL debugging messsages in Contiki, we can follow the "bouncing ball" of RPL on just two nodes.

References

• IPSO RPL White Paper. Good place to start learning about RPL.
• Routing Over Low power and Lossy networks (roll) IETF working group creating RPL
• draft-ietf-roll-rpl-19. The spec. It's dense.
• ROLL Docs. In particular, check out the requirements docs, in the RFC's section.

Preparing

Fortunately, there are no changes needed to make this work. However, in order to follow this all we need debugging in all RPL modules.

$&amp;nbsp;cd&amp;nbsp;core/net/rpl&lt;br/&gt; $&amp;nbsp;sed&nbsp;-i.bak&nbsp;"s/DEBUG_NONE/DEBUG_PRINT/g"&nbsp;*.c<br/>

Building

$&amp;nbsp;cd&amp;nbsp;examples/ipv6/rpl-collect&lt;br/&gt; $&amp;nbsp;make&nbsp;TARGET=avr-zigduino&nbsp;savetarget<br/> $&amp;nbsp;make&amp;nbsp;PERIOD=15&amp;nbsp;-j10&lt;br/&gt; $&amp;nbsp;make&nbsp;udp-sender.avr-zigduino.u&nbsp;AVRDUDE_PORT=/dev/ttyUSB0<br/> $&amp;nbsp;make&amp;nbsp;udp-sink.avr-zigduino.u&amp;nbsp;AVRDUDE_PORT=/dev/ttyUSB1&lt;br/&gt; $&amp;nbsp;make&nbsp;login&nbsp;AVRDUDE_PORT=/dev/ttyUSB1<br/>

Running

Sink, alone

First, bring the sink up alone. I've powered off the sender, just to watch the sink go through its bootup with no interference.

*******Booting&nbsp;Contiki-2.5-1347-g3fae493*******<br/> MAC&nbsp;address&nbsp;2:11:22:ff:fe:33:44:3<br/> nullmac&nbsp;sicslowmac,&nbsp;channel&nbsp;26<br/> Routing&nbsp;Enabled<br/> RPL&nbsp;started<br/> Autostart&nbsp;other&nbsp;processes<br/> I&nbsp;am&nbsp;sink!<br/> <br/> IP&nbsp;addresses&nbsp;[4&nbsp;max]<br/> fdfd::3<br/> fe80::11:22ff:fe33:4403<br/> UDP&nbsp;server&nbsp;started<br/> RPL:&nbsp;Node&nbsp;set&nbsp;to&nbsp;be&nbsp;a&nbsp;DAG&nbsp;root&nbsp;with&nbsp;DAG&nbsp;ID&nbsp;aaaa::1<br/> RPL:&nbsp;Prefix&nbsp;set&nbsp;-&nbsp;will&nbsp;announce&nbsp;this&nbsp;in&nbsp;DIOs<br/> created&nbsp;a&nbsp;new&nbsp;RPL&nbsp;dag<br/> Server&nbsp;IPv6&nbsp;addresses:&nbsp;::<br/> aaaa::1<br/> fdfd::3<br/> fe80::11:22ff:fe33:4403<br/> Created&nbsp;a&nbsp;server&nbsp;connection&nbsp;with&nbsp;remote&nbsp;address&nbsp;::&nbsp;local/remote&nbsp;port&nbsp;5688/8775<br/> RPL:&nbsp;Sending&nbsp;prefix&nbsp;info&nbsp;in&nbsp;DIO&nbsp;for&nbsp;aaaa::<br/> RPL:&nbsp;Sending&nbsp;a&nbsp;multicast-DIO&nbsp;with&nbsp;rank&nbsp;256<br/>

Repeats last 2 lines forever.

Sender Joins

Now, we power up the sender and watch it boot up.

*******Booting&nbsp;Contiki-2.5-1347-g3fae493*******<br/> MAC&nbsp;address&nbsp;2:11:22:ff:fe:33:44:1<br/> nullmac&nbsp;sicslowmac,&nbsp;channel&nbsp;26<br/> Routing&nbsp;Enabled<br/> RPL&nbsp;started<br/> Autostart&nbsp;other&nbsp;processes<br/> <br/> IP&nbsp;addresses&nbsp;[4&nbsp;max]<br/> fdfd::1<br/> fe80::11:22ff:fe33:4401<br/>

Starts the UDP Client, assumes an auto-configured aaaa::/64 address UDP&nbsp;client&nbsp;process&nbsp;started<br/> Client&nbsp;IPv6&nbsp;addresses:&nbsp;aaaa::11:22ff:fe33:4401<br/> fdfd::1<br/> fe80::11:22ff:fe33:4401<br/> Created&nbsp;a&nbsp;connection&nbsp;with&nbsp;the&nbsp;server&nbsp;::&nbsp;local/remote&nbsp;port&nbsp;8775/5688<br/>

Looks for a DODAG

RPL:&nbsp;Sending&nbsp;a&nbsp;DIS<br/>

Gets DIO from root (4403), rank 256 (1.0). Joins the DAG, attaches to 4403 as parent, adds a default route through the parent.

RPL:&nbsp;Received&nbsp;a&nbsp;DIO&nbsp;from&nbsp;fe80::11:22ff:fe33:4403<br/> RPL:&nbsp;Neighbor&nbsp;added&nbsp;to&nbsp;neighbor&nbsp;cache&nbsp;fe80::11:22ff:fe33:4403,&nbsp;02:11:22:ff:fe:33:44:03<br/> RPL:&nbsp;Incoming&nbsp;DIO&nbsp;rank&nbsp;256<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;2,&nbsp;length:&nbsp;6<br/> RPL:&nbsp;DAG&nbsp;MC:&nbsp;type&nbsp;7,&nbsp;flags&nbsp;8,&nbsp;aggr&nbsp;0,&nbsp;prec&nbsp;0,&nbsp;length&nbsp;2,&nbsp;ETX&nbsp;0<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;4,&nbsp;length:&nbsp;14<br/> RPL:&nbsp;DIO&nbsp;Conf:dbl=8,&nbsp;min=12&nbsp;red=10&nbsp;maxinc=768&nbsp;mininc=256&nbsp;ocp=1&nbsp;d_l=255&nbsp;l_u=65535<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;8,&nbsp;length:&nbsp;30<br/> RPL:&nbsp;Copying&nbsp;prefix&nbsp;information<br/> RPL:&nbsp;Adding&nbsp;fe80::11:22ff:fe33:4403&nbsp;as&nbsp;a&nbsp;parent:&nbsp;succeeded<br/> RPL:&nbsp;Joined&nbsp;DAG&nbsp;with&nbsp;instance&nbsp;ID&nbsp;0,&nbsp;rank&nbsp;1536,&nbsp;DAG&nbsp;ID&nbsp;aaaa::1<br/> RPL:&nbsp;Adding&nbsp;default&nbsp;route&nbsp;through&nbsp;fe80::11:22ff:fe33:4403<br/>

Now starts SENDING a DIO for downstream nodes to pick up, but assumes a very high rank, 1536 (6.0). Ultimately we will have a much better rank once we establish an ETX with our parent. But for now, we presume we are ridiculously far from our parent.

RPL:&nbsp;Sending&nbsp;prefix&nbsp;info&nbsp;in&nbsp;DIO&nbsp;for&nbsp;aaaa::<br/> RPL:&nbsp;Sending&nbsp;a&nbsp;multicast-DIO&nbsp;with&nbsp;rank&nbsp;1536<br/>

Gets the DIO from 4403 again. These are going to happen all the time now. That last line, "Received consistent DIO" is a nice way of saying, "This DIO is pointless, I don't need to do anything."

RPL:&nbsp;Received&nbsp;a&nbsp;DIO&nbsp;from&nbsp;fe80::11:22ff:fe33:4403<br/> RPL:&nbsp;Neighbor&nbsp;already&nbsp;in&nbsp;neighbor&nbsp;cache<br/> RPL:&nbsp;Incoming&nbsp;DIO&nbsp;rank&nbsp;256<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;2,&nbsp;length:&nbsp;6<br/> RPL:&nbsp;DAG&nbsp;MC:&nbsp;type&nbsp;7,&nbsp;flags&nbsp;8,&nbsp;aggr&nbsp;0,&nbsp;prec&nbsp;0,&nbsp;length&nbsp;2,&nbsp;ETX&nbsp;0<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;4,&nbsp;length:&nbsp;14<br/> RPL:&nbsp;DIO&nbsp;Conf:dbl=8,&nbsp;min=12&nbsp;red=10&nbsp;maxinc=768&nbsp;mininc=256&nbsp;ocp=1&nbsp;d_l=255&nbsp;l_u=65535<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;8,&nbsp;length:&nbsp;30<br/> RPL:&nbsp;Copying&nbsp;prefix&nbsp;information<br/> RPL:&nbsp;Received&nbsp;consistent&nbsp;DIO<br/>

Sends out a DAO to 4403, and establishes a perfect ETX. That's what we expect because the nodes are right next to each other!

RPL:&nbsp;Sending&nbsp;DAO&nbsp;with&nbsp;prefix&nbsp;aaaa::11:22ff:fe33:4401&nbsp;to&nbsp;fe80::11:22ff:fe33:4403<br/> RPL:&nbsp;Neighbor&nbsp;fe80::11:22ff:fe33:4403&nbsp;is&nbsp;known.&nbsp;ETX&nbsp;=&nbsp;1<br/>

Still sending that very high rank DIO out, 1536 (6.0). Not sure why. I guess it hasn't recalculated its rank yet.

RPL:&nbsp;Sending&nbsp;prefix&nbsp;info&nbsp;in&nbsp;DIO&nbsp;for&nbsp;aaaa::<br/> RPL:&nbsp;Sending&nbsp;a&nbsp;multicast-DIO&nbsp;with&nbsp;rank&nbsp;1536<br/>

Ok, now it's going to recalculate its rank to the proper 512 (2.0).

RPL:&nbsp;Moving&nbsp;in&nbsp;the&nbsp;DAG&nbsp;from&nbsp;rank&nbsp;6&nbsp;to&nbsp;2<br/> RPL:&nbsp;The&nbsp;preferred&nbsp;parent&nbsp;is&nbsp;fe80::11:22ff:fe33:4403&nbsp;(rank&nbsp;1)<br/>

And now it starts sending out DIO's for other children. These are going to be sent all the time now. Too frequently, IMO.

RPL:&nbsp;Sending&nbsp;prefix&nbsp;info&nbsp;in&nbsp;DIO&nbsp;for&nbsp;aaaa::<br/> RPL:&nbsp;Sending&nbsp;a&nbsp;multicast-DIO&nbsp;with&nbsp;rank&nbsp;512<br/>

Send an rpl-collect packet.

In&nbsp;udp_send<br/> Sending&nbsp;packet&nbsp;with&nbsp;length&nbsp;94&nbsp;(54)<br/>

And from here, it's an endless repeat of...

• Sending a rank 512 DIO
• Receiving a rank 256 DIO from 4403
• Sending rpl-collect data on UDP

Sink, after sender arrives

Now let's go back and pick up with the sink, and watch the action as the sender joins the DODAG.

Got a DIS from 4401

RPL:&nbsp;Received&nbsp;a&nbsp;DIS&nbsp;from&nbsp;fe80::11:22ff:fe33:4401<br/> RPL:&nbsp;Multicast&nbsp;DIS&nbsp;=&gt;&nbsp;reset&nbsp;DIO&nbsp;timer<br/>

Send out a DIO, rank 256 (1.0)

RPL:&nbsp;Sending&nbsp;prefix&nbsp;info&nbsp;in&nbsp;DIO&nbsp;for&nbsp;aaaa::<br/> RPL:&nbsp;Sending&nbsp;a&nbsp;multicast-DIO&nbsp;with&nbsp;rank&nbsp;256<br/>

Got a DIO from 4401, rank 1536 (6.0). We will ignore the DAG advertised, because of the high rank (and because we're the root). This is the first time we've heard from 4401, so we will add it to our cache.

RPL:&nbsp;Received&nbsp;a&nbsp;DIO&nbsp;from&nbsp;fe80::11:22ff:fe33:4401<br/> RPL:&nbsp;Neighbor&nbsp;added&nbsp;to&nbsp;neighbor&nbsp;cache&nbsp;fe80::11:22ff:fe33:4401,&nbsp;02:11:22:ff:fe:33:44:01<br/> RPL:&nbsp;Incoming&nbsp;DIO&nbsp;rank&nbsp;1536<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;2,&nbsp;length:&nbsp;6<br/> RPL:&nbsp;DAG&nbsp;MC:&nbsp;type&nbsp;7,&nbsp;flags&nbsp;8,&nbsp;aggr&nbsp;0,&nbsp;prec&nbsp;0,&nbsp;length&nbsp;2,&nbsp;ETX&nbsp;640<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;4,&nbsp;length:&nbsp;14<br/> RPL:&nbsp;DIO&nbsp;Conf:dbl=8,&nbsp;min=12&nbsp;red=10&nbsp;maxinc=768&nbsp;mininc=256&nbsp;ocp=1&nbsp;d_l=255&nbsp;l_u=65535<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;8,&nbsp;length:&nbsp;30<br/> RPL:&nbsp;Copying&nbsp;prefix&nbsp;information<br/>

Routine DIO advertisement. These will happen all the time now.

RPL:&nbsp;Sending&nbsp;prefix&nbsp;info&nbsp;in&nbsp;DIO&nbsp;for&nbsp;aaaa::<br/> RPL:&nbsp;Sending&nbsp;a&nbsp;multicast-DIO&nbsp;with&nbsp;rank&nbsp;256<br/>

Got the DAO from 4401, so we can add a route to it as well.

RPL:&nbsp;Received&nbsp;a&nbsp;DAO&nbsp;from&nbsp;fe80::11:22ff:fe33:4401<br/> RPL:&nbsp;DAO&nbsp;lifetime:&nbsp;255,&nbsp;prefix&nbsp;length:&nbsp;128&nbsp;prefix:&nbsp;aaaa::11:22ff:fe33:4401<br/> RPL:&nbsp;Added&nbsp;a&nbsp;route&nbsp;to&nbsp;aaaa::11:22ff:fe33:4401/128&nbsp;via&nbsp;fe80::11:22ff:fe33:4401<br/>

Another DIO from 4401. Ignore. Frankly, I am a little confused by this DIO. It has a proper ETX (128 aka 1.0), but still a high rank (1536 aka 6.0). The next DIO after this one will have the right ETX and the right Rank.

RPL:&nbsp;Received&nbsp;a&nbsp;DIO&nbsp;from&nbsp;fe80::11:22ff:fe33:4401<br/> RPL:&nbsp;Neighbor&nbsp;already&nbsp;in&nbsp;neighbor&nbsp;cache<br/> RPL:&nbsp;Incoming&nbsp;DIO&nbsp;rank&nbsp;1536<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;2,&nbsp;length:&nbsp;6<br/> RPL:&nbsp;DAG&nbsp;MC:&nbsp;type&nbsp;7,&nbsp;flags&nbsp;8,&nbsp;aggr&nbsp;0,&nbsp;prec&nbsp;0,&nbsp;length&nbsp;2,&nbsp;ETX&nbsp;128<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;4,&nbsp;length:&nbsp;14<br/> RPL:&nbsp;DIO&nbsp;Conf:dbl=8,&nbsp;min=12&nbsp;red=10&nbsp;maxinc=768&nbsp;mininc=256&nbsp;ocp=1&nbsp;d_l=255&nbsp;l_u=65535<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;8,&nbsp;length:&nbsp;30<br/> RPL:&nbsp;Copying&nbsp;prefix&nbsp;information<br/>

Another DIO from 4401. At least this has the proper rank now. Ignore it. These will continue forever.

RPL:&nbsp;Received&nbsp;a&nbsp;DIO&nbsp;from&nbsp;fe80::11:22ff:fe33:4401<br/> RPL:&nbsp;Neighbor&nbsp;already&nbsp;in&nbsp;neighbor&nbsp;cache<br/> RPL:&nbsp;Incoming&nbsp;DIO&nbsp;rank&nbsp;512<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;2,&nbsp;length:&nbsp;6<br/> RPL:&nbsp;DAG&nbsp;MC:&nbsp;type&nbsp;7,&nbsp;flags&nbsp;8,&nbsp;aggr&nbsp;0,&nbsp;prec&nbsp;0,&nbsp;length&nbsp;2,&nbsp;ETX&nbsp;128<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;4,&nbsp;length:&nbsp;14<br/> RPL:&nbsp;DIO&nbsp;Conf:dbl=8,&nbsp;min=12&nbsp;red=10&nbsp;maxinc=768&nbsp;mininc=256&nbsp;ocp=1&nbsp;d_l=255&nbsp;l_u=65535<br/> RPL:&nbsp;DIO&nbsp;suboption&nbsp;8,&nbsp;length:&nbsp;30<br/> RPL:&nbsp;Copying&nbsp;prefix&nbsp;information<br/>

Got some real rpl-collect data! Print it. These will continue forever now.

Receiving&nbsp;UDP&nbsp;packet<br/> In&nbsp;udp_found<br/> 30&nbsp;0&nbsp;205&nbsp;0&nbsp;17409&nbsp;1&nbsp;1&nbsp;0&nbsp;22&nbsp;2557&nbsp;0&nbsp;0&nbsp;0&nbsp;0&nbsp;0&nbsp;836&nbsp;8&nbsp;512&nbsp;1&nbsp;8&nbsp;0&nbsp;0&nbsp;0&nbsp;0&nbsp;0&nbsp;0&nbsp;0&nbsp;0&nbsp;0&nbsp;0<br/> In&nbsp;udp_send<br/>