Using:RPL

dak664 edited this page Jan 24, 2012 · 5 revisions

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

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

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.

$ cd core/net/rpl
$ sed -i.bak "s/DEBUG_NONE/DEBUG_PRINT/g" *.c

Building

$ cd examples/ipv6/rpl-collect
$ make TARGET=avr-zigduino savetarget
$ make PERIOD=15 -j10
$ make udp-sender.avr-zigduino.u AVRDUDE_PORT=/dev/ttyUSB0
$ make udp-sink.avr-zigduino.u AVRDUDE_PORT=/dev/ttyUSB1
$ make login AVRDUDE_PORT=/dev/ttyUSB1

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 Contiki-2.5-1347-g3fae493*******
MAC address 2:11:22:ff:fe:33:44:3
nullmac sicslowmac, channel 26
Routing Enabled
RPL started
Autostart other processes
I am sink!

IP addresses [4 max]
fdfd::3
fe80::11:22ff:fe33:4403
UDP server started
RPL: Node set to be a DAG root with DAG ID aaaa::1
RPL: Prefix set - will announce this in DIOs
created a new RPL dag
Server IPv6 addresses: ::
aaaa::1
fdfd::3
fe80::11:22ff:fe33:4403
Created a server connection with remote address :: local/remote port 5688/8775
RPL: Sending prefix info in DIO for aaaa::
RPL: Sending a multicast-DIO with rank 256

Repeats last 2 lines forever.

Sender Joins

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

*******Booting Contiki-2.5-1347-g3fae493*******
MAC address 2:11:22:ff:fe:33:44:1
nullmac sicslowmac, channel 26
Routing Enabled
RPL started
Autostart other processes

IP addresses [4 max]
fdfd::1
fe80::11:22ff:fe33:4401

Starts the UDP Client, assumes an auto-configured aaaa::/64 address

UDP client process started
Client IPv6 addresses: aaaa::11:22ff:fe33:4401
fdfd::1
fe80::11:22ff:fe33:4401
Created a connection with the server :: local/remote port 8775/5688

Looks for a DODAG

RPL: Sending a DIS

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

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: Sending prefix info in DIO for aaaa::
RPL: Sending a multicast-DIO with rank 1536

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

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: Sending DAO with prefix aaaa::11:22ff:fe33:4401 to fe80::11:22ff:fe33:4403
RPL: Neighbor fe80::11:22ff:fe33:4403 is known. ETX = 1

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

RPL: Sending prefix info in DIO for aaaa::
RPL: Sending a multicast-DIO with rank 1536

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

RPL: Moving in the DAG from rank 6 to 2
RPL: The preferred parent is fe80::11:22ff:fe33:4403 (rank 1)

And now it starts sending out DIO's for other children. These are going to be sent all the time now, at a rate set by the "trickle timer". The initial interval is doubled up to some maximum interval as indicated by the DIO fields DIO dbl=8, min=12, integers that represent seconds to a power of two. These times are to be chosen as a compromise between network overhead and network repair. However the timer is reset back to minimum upon reception of a multicast DIS or when a network inconsistency has been discovered, such as loop formation in the DAG. Using leaf nodes when possible will reduce this overhead, as they do not send DIO's.

RPL: Sending prefix info in DIO for aaaa::
RPL: Sending a multicast-DIO with rank 512

Send an rpl-collect packet.

In udp_send
Sending packet with length 94 (54)

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: Received a DIS from fe80::11:22ff:fe33:4401
RPL: Multicast DIS => reset DIO timer

Send out a DIO, rank 256 (1.0)

RPL: Sending prefix info in DIO for aaaa::
RPL: Sending a multicast-DIO with rank 256

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

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

RPL: Sending prefix info in DIO for aaaa::
RPL: Sending a multicast-DIO with rank 256

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

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

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

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

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

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

Receiving UDP packet
In udp_found
30 0 205 0 17409 1 1 0 22 2557 0 0 0 0 0 836 8 512 1 8 0 0 0 0 0 0 0 0 0 0
In udp_send