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

From: "Liubing (Remy)" <[email-masked]>
Date: Tue, 10 Apr 2018 01:34:59 +0000

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

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Sat, 21 Apr 2018 03:50:52 +0000

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:[email-masked]] On Behalf Of Liubing (Remy)
Sent: 10 April 2018 09:35
To: [email-masked]
Subject: [Roll] Updates of AODV-RPL since IETF101

Hello ROLL,

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.

Best regards,
Remy

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Liubing (Remy)" <[email-masked]>
Date: Mon, 23 Apr 2018 10:06:45 +0000

Hello Rahul,

Thank you for your comments. 

Yes, the RREP-DIO should be unicast hop-by-hop from the TargNode to the OrigNode.

I just realized that for the second scenario that I've described, even for symmetric route, it can also happen. Therefore, the RREP-DIO MUST carry exactly one target option for both symmetric and asymmetric routes.

Best regards,
Remy

> From: Roll [mailto:[email-masked]] On Behalf Of Rahul Arvind Jadhav
> Sent: Saturday, April 21, 2018 11:51 AM
> To: Routing Over Low power and Lossy networks <[email-masked]>
> Subject: 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
> 
> 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.
> 
> 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. P
>  r  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.
>

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Wed, 25 Apr 2018 00:28:22 +0000

Thanks Remy,

Thus I assume T bit will be removed? 

Another Question: Section 6.3.3. last para talks about handling paired instanceID collision on TargNode. The details are insufficient regarding how to handle "shifting of instanceID".  RREP option has SHIFT field to indicate the shifting, but when it reaches OrigNode and if the resulting shifted instanceID is already in use by OrigNode then how should the handling be? How to clean-up the states established on 6LRs because of previous RREQ-DIO instance? Will shifting result in another round of RREQ-DIO, RREP-DIO ?
IMO, this warrants a separate section.

Regards,
Rahul

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of Liubing (Remy)
Sent: 23 April 2018 18:07
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Updates of AODV-RPL since IETF101

Hello Rahul,

Best regards,
Remy

> 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.
> 
> 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."
> process it anymore. You need unicast hop-by-hop DIO to be used for 
> this so that intermediate 6LRs can process it.
> 
> Regards,
> Rahul
> 
> 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.
> 
> 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. P
> 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?
>

---

From: "Liubing (Remy)" <[email-masked]>
Date: Wed, 25 Apr 2018 01:48:14 +0000

Hello Rahul,

Yes, the T bit will be removed.

Thanks for raising a good point about the SHIFT field. We will add a section talking about this.

The "shifting of instanceID" is used to distinguish the two RREP-instances at the TargNode, when two OrigNodes happen to use the same local InstanceIDs to the same TargNode. Any intermediate node should rebroadcast the RREP-DIO without changing the (shifted) InstanceID. However, when building routing state in hop-by-hop mode ('H'=1) at an intermediate node, the original InstanceID (shift back) should be used. When receiving the RREP-DIO, the OrigNode will shift back to the original InstanceID. Since the original InstanceID is assigned by the OrigNode, there should be no conflict. There is no need to have another round of RREQ-DIO and RREP-DIO if the routes are found successfully. The states established on 6LRs will timeout eventually if they are not used for packet forwarding.

Best regards,
Remy

> Sent: Wednesday, April 25, 2018 8:28 AM
> Another Question: Section 6.3.3. last para talks about handling paired
> instanceID collision on TargNode. The details are insufficient regarding how
> to handle "shifting of instanceID".  RREP option has SHIFT field to indicate the
> shifting, but when it reaches OrigNode and if the resulting shifted instanceID
> is already in use by OrigNode then how should the handling be? How to
> clean-up the states established on 6LRs because of previous RREQ-DIO
> instance? Will shifting result in another round of RREQ-DIO, RREP-DIO ?
> I just realized that for the second scenario that I've described, even for
> symmetric route, it can also happen. Therefore, the RREP-DIO MUST carry
> exactly one target option for both symmetric and asymmetric routes.
> 
> Best regards,
> Remy
> 
> > 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. P