[Roll] Updates of AODV-RPL since IETF101

["Liubing (Remy)" <[e-mail]>]

Hello ROLL,

We are working on the revision of AODV-RPL. Hopefully, we will submit the next version very soon.

In the current draft, a 'T' bit is used in the RREP-DIO, when it is clear, the Target Option encapsulating the OrigNode's address can be elided. Recently, we discovered that if local InstanceID is used for the RREQ and RREP instances, in RREP-DIO the Target Option MUST be present.

This is due to the following two reasons:

1. The first reason is related to the route entries built in hop-by-hop mode. We think one route entry should have at least the following items: the route's source and destination addresses, InstanceID, next-hop, lifetime. Because the Instance ID is locally assigned, so it should be used with the source address, which is the DODAGID. For the a upward route entry, all the items can be learnt by related fields in the RREQ-DIO. For an intermediate node not on the upward route, it won't get the source address for the downward route entry if the Target Option (including the OrigNode's address) is elided in the RREP-DIO, even though the InstanceID is well paired without any conflict.

2. The second reason is to solve the corner case when two router happen to use the same local instanceID to do RD to the same TargNode. For example, Node A and B are trying to find routes to C, coincidentally, they use the same InstanceID. They both are not aware of this situation when they send out the RREQs, because the InstanceID is assigned locally.  When A's RREQ arrives at C earlier than B' RREQ, C will send out the RREP-DIO to build route to A. The InstanceID of RREP-DIO is paired to A's RREQ-DIO, and A's address is elided ('T'=0). When receive B's RREQ, C will use another number shifted from the original one as the instanceID is already used by the RREP for A. (But B is not aware of this.) When the RREP-DIO dedicated for A arrives at B, B thinks this RREP-DIO is for itself by identify the paired InstanceID and the DODAGID (which is C's address). In this case, B will build route to C, but the routes follows A's requirements not B's. And B will not forward the RREP-DIO to A. Probably, A will never get its RREP.

Therefore, if local instanceID is used, the RREP-DIO for asymmetric route MUST have exactly one target option, and the 'T' bit in RREP option is no longer needed in this case. For symmetric route, the RREP-DIO is unicast to the OrigNode, the Target Option can be elided, because the addresses can be learnt from the IPv6 header of RREP-DIO.

Another solution to solve this problem is to use global InsanceID, which is 128 in total. Is this a feasible solution?

Looking forward to your comments.

Best regards,
Remy