-
Notifications
You must be signed in to change notification settings - Fork 17
Using:RPL
Navigation: Home | Scenarios | Installing | Using | Future
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.
- 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.
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
$ 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
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.
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. Too frequently, IMO.
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
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