mac80211: increment the seqnum of PREP whenever PREQ is processed

[chunyeow]

Mesh STA A [mesh0] <----> [mesh0] Mesh STA B [mesh1] <---> [mesh0] Mesh STA C

In the case, when RANN is generated by Mesh STA A, to Mesh STA B and Mesh STA C,
PREQs are generated by both Mesh STA B and Mesh STA C respectively. Mesh STA A
will receive both PREQ from Mesh STA A and Mesh STA C almost at the same time.
In current implementation, the sequence number is not increment due to purpose
of providing path stability in short term using dot11MeshHWMPnetDiameterTraversalTime
and this has caused Mesh STA C to resend two PREQs whenver receving RANN from Mesh
STA A. This patch is intended to increment the sequence number so that Mesh STA B
not dropping the PREP from Mesh STA A destined to Mesh STA C at first try.

Signed-off-by: Chun-Yeow Yeoh [email protected]

[twpedersen]

"Mesh STA A
will receive both PREQ from Mesh STA A and Mesh STA C almost at the same time." should probable be "... from Mesh STA B and Mesh STA C ..."

[chunyeow]

Yes, it should be PREQs from both Mesh STA B and Mesh STA C.

ifmsh->sn is the local mesh sequence number, why are you assigning the target_sn?

Target Sequence Number in the PREQ element is the latest HWMP sequence number stored by the originator mesh STA for the target mesh STA. So once the target mesh STA received it, as according to section 11C.9.8.3 (HWMP sequence numbering), it shall update its own HWMP sequence number to maximum (current HWMP sequence number, target HWMP sequence number in the PREQ) + 1 immediately before it generates a PREP in response to a PREQ.

Now we unconditionally increment the target SN after receiving a PREQ? Why?

So, if ifmsh->sn is less than target_sn, we maximize it and plus 1 for our PREP generation as target mesh STA. Then, the originator mesh STA can decide which is the better path after receiving more than one PREPs.

I think that the previous implementation is to ensure path stability in short term. So that the originator mesh STA will stick to the path from the first received PREP from its target mesh STA within the net_traversal_interval. This is because the originator mesh STA will drop the subsequent PREPs if the target HWMP sequence number is not updated. The paper entitled "A joint experimental and simulation study of the IEEE 802.11s HWMP protocol and airtime link metric", section "The non-increasing DSN option", explains this better.

target SN after receiving a PREQ? Why?

I have one problem when Mesh STA B with dual radio support and RANN is turned on at Mesh STA A. Whenever a RANN is received by both Mesh STA B and C, both of them generates the PREQ to mesh STA A. Mesh STA A replies with PREP to mesh STA B and PREP to mesh STA C via mesh STA B. It happens that the 1st PREP destined to mesh STA B with an updated target_sn but 2nd PREP to mesh STA C without an updated target_sn, the hwmp_route_info_get happens to drop the frame due to this. Thus, mesh STA C will again generate another PREQ. So for each RANN, mesh STA C will generate two PREQs. This will cause excessive number of PREQs if the number of mesh STAs is increased.

Please join us on IRC @ internal.o11s.org #lounge

Need authentication on this? Is a openwrt platform.

[twpedersen]

How do I respond inline? :P

Target Sequence Number in the PREQ element is the latest HWMP sequence number stored by the originator mesh STA for the target mesh STA.

Yes, but ifmsh->sn is the data frame sequence number. The HWMP SN is stored in mpath->SN?

The paper entitled "A joint experimental and simulation study of the IEEE 802.11s HWMP protocol and airtime link metric", section "The non-increasing DSN option", explains this better.

OK. Thanks.

This will cause excessive number of PREQs if the number of mesh STAs is increased.

OK makes sense.

Need authentication on this? Is a openwrt platform

Right, sorry. We'll need to authorize your public key. I'll ask about this, but probably better to have an open o11s channel in general.

[chunyeow]

If we are the final recipient of the PREQ element, the target HWMP SN of the generated PREP element is based on our ifmsh->sn.

[chunyeow]

ifmsh->sn is our own HWMP SN and mpath->sn is the target HWMP SN. If we are the PREQ is destined for us, the PREP element's target HWMP SN is our own HWMP SN and originator HWMP SN is remained the same as PREQ element.

[bcopeland]

I guess it's also worth pointing out the XXX comment above the change -- we use ifmsh->sn from the wrong interface.

I think it should at least be something like:

iface = mesh_bss_find_if(mbss, target_addr);
if (iface) {
ifmsh = &iface->u.mesh;
[...]
}

...but I haven't really digested the above conversation yet.

[twpedersen]

Chun-Yeow,

You're right, ifmsh->sn is the HWMP SN and ifmsh->mesh_seqnum is the mesh sequence number.

[chunyeow]

Hi, Bob

I am not too sure about this. But this patch is actually applicable on mesh STA A which only have one mesh interface. So ifmsh->sn should be correct.

By the way, are we able to assign a specific IP address for mesh node with multiple interfaces. How?

[twpedersen]

Hi Chun-Yeow,

I read the paper you referenced (thanks! :)), and this change makes sense, but don't you really want to remove the netdiametertraversal thing entirely? It seems with this patch you're disabling it anyway. Also this patch is not strictly related to multi-if, so a patch submission to o11s-devel would be fine.

Thomas

[chunyeow]

Hi, Thomas

I think that during the PREQ generation by mesh_path_start_discovery, the Sequence Number is increased after the HWMP net diameter traversal time which is as defined by 802.11s-2011 section 11C.9.8.6

In this case, the originator HWMP SN shall be incremented only after at least dot11MeshHWMPnetDiameterTraversalTime has elapsed since the previous increment.

So it should remain. But for PREP generation, the netdiametertraversal seems to be implementation specific by o11s. Previously, this has not caused problem of duplicate PREQ frames, only happens when multi-if nodes are deployed.

---

Chun-Yeow

[twpedersen]

Makes sense, but the improper reverse path (PREP) metric detection due to one having a higher sequence number (as described in the paper) would still take place in a single-channel mesh.