Subject: [Roll] Explaining RPLinstance pairing and shift

From: "Liubing (Remy)" <[email-masked]>
Date: Wed, 18 Jul 2018 13:37:32 +0000

Hello Pascal,

Regarding to the discussion that we had at the meeting, I'd like to explain the motivation for RPLInstance pairing and Shift.

Why we need RPLInstance pairing?
Multiple instances can coexist between the same pair of OrigNode and TargNode at the same time, if two applications running on the TargNode have different requirements on routes to the same TargNode, thus the routes need to be built separately. In order to match the RREP-DIO to the correct RREQ-DIO, the RPLInstanceID must be paired. One convenient option is to let the RREQ-instance and the RREP-instance share the same ID. And there will be no conflict because the RPLInstanceID is local and the RREQ and RREP instances have different DODAGIDs. There can be other ways for pairing but will result in extra overhead because the ID of the RREQ-instance needs to be carried somehow.

Why we need the shift?
Two OrigNodes may use the same local RPLInstaceID to find routes to the same TargNode at the same time. According to the previous RPLInstaceID pairing mechanism, the IDs of the two RREP-instances will be the same as well. However, it is obligate to differentiate the two RREP-instances. That's why we need to shift the instance ID to another one at the TargNode. The original instance ID can be recovered whenever needed at the intermediate nodes or the OrigNode.

Many thanks for agreeing to review our draft.

Best regards,
Remy

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 18 Jul 2018 21:29:42 +0000

Hello Remy :

I agree with all that. My point was more a format question and does not suggest a change of design.

The tuple (IPv6 @, instance ID) identifies uniquely a DODAG. In the case of a local instance, the name space of the instance ID is local to the node that owns the IPv6 address. So far so good.

With AODV RPL, the caller IP1 forms a tuple (IP1, ID1) for the DODAG 1 associated to the RREQ, and the responder IP2 forms another (IP2, ID2) for the DODAG 2 associated to the reply.  The packets from the caller are tagged with (IP2, ID2) while packets from the responder are tagged (IP1, ID1).

If you look at it this is very similar to a user-SAP, provider-SAP in OSI. My only question was this idea of shifting. Why call things shifts when the point is that these are different and unrelated instance IDs, from different namespaces? The OSI response to a create_SAP.req(usap) is a create_SAP.conf(uSAP, pSAP) and then for the data we have data.req(pSAP)  and data.ind(uSAP).

I thought you'd use that classical model. I expected that the RREP that forms the DODAG 2 identified by (IP2, ID2 )would have a new option in it, like a ID-correlator option that would contain (IP1, ID1). So people that see the RREP can correlate the 2 easily.

Do I make sense?

Pascal

From: Liubing (Remy) <[email-masked]>
Sent: mercredi 18 juillet 2018 09:38
To: Pascal Thubert (pthubert) <[email-masked]>; Charlie Perkins <[email-masked]>
Cc: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Explaining RPLinstance pairing and shift

Hello Pascal,

Why we need the shift?

Best regards,
Remy

---

From: "Liubing (Remy)" <[email-masked]>
Date: Thu, 19 Jul 2018 15:45:20 +0000

Hello Pascal,

Thank you very much for your comments.

Your solution is doable and straightforward for comprehension. You’re suggesting that the second DODAG uses (IP2, ID2) and carries (IP1, ID1) as an option. Our pairing and shifting mechanisms have the same functionality. Our solution is to use (IP2, ID1) for the RREP DODAG, and IP1 is carried in the Target Option. If ID1 is already occupied at IP2, a shift is needed.

These two solutions are all designed for “corner cases”: in most cases, there is only one instance between a pair of OrigNode and TargNode, and it’s rare that two OrigNodes use the same RPLinstanceID to build routes to the same TargNode.

The advantage of our solution is that it has no extra overhead in most cases, because no extra option is needed.

Best regards,
Remy
发件人: Pascal Thubert (pthubert) [mailto:[email-masked]]
发送时间: 2018年7月19日 5:30
收件人: Liubing (Remy) <[email-masked]>; Charlie Perkins <[email-masked]>
抄送: Routing Over Low power and Lossy networks <[email-masked]>
主题: RE: Explaining RPLinstance pairing and shift
Hello Remy :

I thought you’d use that classical model. I expected that the RREP that forms the DODAG 2 identified by (IP2, ID2 )would have a new option in it, like a ID-correlator option that would contain (IP1, ID1). So people that see the RREP can correlate the 2 easily.

Do I make sense?

Pascal

From: Liubing (Remy) <[email-masked]<mailto:[email-masked]>>
Sent: mercredi 18 juillet 2018 09:38
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Charlie Perkins <[email-masked]<mailto:[email-masked]>>
Cc: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: Explaining RPLinstance pairing and shift

Hello Pascal,

Regarding to the discussion that we had at the meeting, I’d like to explain the motivation for RPLInstance pairing and Shift.

Why we need the shift?
Two OrigNodes may use the same local RPLInstaceID to find routes to the same TargNode at the same time. According to the previous RPLInstaceID pairing mechanism, the IDs of the two RREP-instances will be the same as well. However, it is obligate to differentiate the two RREP-instances. That’s why we need to shift the instance ID to another one at the TargNode. The original instance ID can be recovered whenever needed at the intermediate nodes or the OrigNode.

Best regards,
Remy

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 Jul 2018 16:44:59 +0000

Hello Remy : )

This is not really about < solution” since we agree on the flows. It is about signaling. What’s the most appropriate way to transport (IP1, ID1) back so it is semantically clear and unambiguous.
The draft is overloading target for IP1; It makes sense, so you do not have to put it twice in the packet. Still I see that as a compression, a reference. Signaling wise, I’m OK to make the ID2 an option just before the target it relates to. I’m not happy with calling things a shift. It is a different ID from a different space. Just call it an ID.

Anyway, I’ll understand better when I review the all draft as promised…

Cheers,

Pascal

From: Liubing (Remy) <[email-masked]>
Sent: jeudi 19 juillet 2018 11:45
To: Pascal Thubert (pthubert) <[email-masked]>; Charlie Perkins <[email-masked]>
Cc: Routing Over Low power and Lossy networks <[email-masked]>
Subject: 答复: Explaining RPLinstance pairing and shift

Hello Pascal,

Best regards,
Remy
发件人: Pascal Thubert (pthubert) [mailto:[email-masked]]
发送时间: 2018年7月19日 5:30
收件人: Liubing (Remy) <[email-masked]<mailto:[email-masked]>>; Charlie Perkins <[email-masked]<mailto:[email-masked]>>
抄送: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
主题: RE: Explaining RPLinstance pairing and shift
Hello Remy :

Do I make sense?

Pascal

Hello Pascal,

Why we need the shift?

Best regards,
Remy