Re: [Roll] Updates of AODV-RPL since IETF101

Yes I understand that the 'T' bit in RREP-DIO cannot be elided because of the reasons you mentioned. It's fairly reasonable to assume that different nodes might end up choosing the same local instance id (given that it is merely 6 bits) to the same TargNode.

Also I don't think using global InstanceID for solving this makes sense at all. One scenario is, some 6LRs choose to be a 6LR only for global instances and avoid been 6LR for local instances, such scenarios will break. I'm sure there will be many more reasons for not using global instance ids for such use-case.

One more point... You mentioned,  " 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."
Unicasting to OrigNode will not work because intermediate 6LRs won't process it anymore. You need unicast hop-by-hop DIO to be used for this so that intermediate 6LRs can process it.

Regards,
Rahul

-----Original Message-----
From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Liubing (Remy)
Sent: 10 April 2018 09:35
To: roll@ietf.org
Subject: [Roll] Updates of AODV-RPL since IETF101

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. Pr  obably, 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

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll