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

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

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

> -----Original Message-----
> From: Roll [mailto:[e-mail]] On Behalf Of Rahul Arvind Jadhav
> Sent: Wednesday, April 25, 2018 8:28 AM
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: Re: [Roll] Updates of AODV-RPL since IETF101
> 
> 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:[e-mail]] On Behalf Of Liubing (Remy)
> Sent: 23 April 2018 18:07
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: Re: [Roll] Updates of AODV-RPL since IETF101
> 
> 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
> 
> > -----Original Message-----
> > From: Roll [mailto:[e-mail]] On Behalf Of Rahul Arvind
> > Jadhav
> > Sent: Saturday, April 21, 2018 11:51 AM
> > To: Routing Over Low power and Lossy networks <[e-mail]>
> > 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
> >
> > -----Original Message-----
> > From: Roll [mailto:[e-mail]] On Behalf Of Liubing (Remy)
> > Sent: 10 April 2018 09:35
> > To: [e-mail]
> > 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. 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.
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> >
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll