Hi Laurent, Thanks for your message!
Please find below some inline responses: > Hi Carles, > > I think is it good to keep App and Dev since they are hardcoded in the > Field ID. Yes, I see the advantage of trying to reuse existing functionality as it is to the extent possible. > The goal will be to determine who's up and down. In openschc we > have a tunnel mode and the SCHC packet is sent over an UDP tunnel. This > allows fast prototyping. In the core side, when an IPv6 packet arrives, > the > Rule Manager look for a validate rule among all the rules of all he > devices. If a rule matches, the RM returns the Device ID that could be a > LPWAN id (such as lorawan:1234567812345678) or the UDP tunnel (udp: > 123.234.123.234:8888) and the packet is sent to the other end. I think your "If a rule matches" is a key point to consider. In the context of a peer-to-peer 802.15.4 network, a matching Rule would state who is "Dev" and who is "App" a priori. That is, if we stick to the "Dev" and "App" roles as they are, trying to use a single Rule for both directions between two endoints, there needs to be some previous agreement on or configuration of which endpoint is "Dev" and which one is "App", for that pair of endpoints. > The other end receives the packet and looks in its own rule manager to > find > the reverse rule. Since the rules are the same on both end, the ID > associated to the rule is of course the one of the device. > > When the device answer, we can generalize the previous behavior. If the > answer matches a rule and the ID of the rule is the own device, then the > SCHC packet has to be sent to the core (which is identified in case of > Lora, send the SCHC packet on the Lora interface, and in case of UDP to > the > IP address of the core learnt in the previous exchange). I don't say that > it will work in mesh network, since we still consider a single core. > If the matching rule has an id different from the device, then the SCHC > packet is sent to that ID has for the core. I see how your example works, but I understand that it is based on some Rules that have been written before communication between the two endpoints actually happens, based on a decision of which endpoint is "Dev" and which one is "App". (Please let me know if it is otherwise...) > Another remark is that we can break symmetry in the rule. In the example > we > gave, for APP* and DEV* Field ID we have always a BI direction. If for > instance, we give DOWN to a DEV* and APP* pair then it will correspond to > the source and destination addresses. If I understand correctly this suggestion, would that mean that the number of Rules would need to be duplicated, since we would need one Rule for one direction and one Rule for the other? Thanks, Carles > My 2 cents > > Laurent _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
