I am reviewing this for the Operations Directorate. I have a few questions. I personally do not have experience in radio mesh networks, and as a result will not be able to comment on the correctness or completeness of the protocol per se. However, I’ve designed a few protocols, and found a few points surprising.

Was a reference implementation built and tested?

The author is an employee of Ember, which is now owned by Silicon Labs. This is a positive thing; Ember is a vendor of mesh networking equipment, which suggests that the author likely has experience and expertise. But it makes me wonder what similarities this protocol might have to Ember/SL proprietary products. There are no IPR disclosures, but I wonder whether there should be, and I wonder whether the title should be “SL’s ...". Note that this is neither an accusation nor an assertion. It’s a “due diligence” question, and with any luck it has been asked and answered. I’m just not personally in possession of the answer, and would like to be sure the AD is.

A nit relating to terminology; IP is at the “Network Layer”, and specifically the “Internet” layer or sublayer. It is not the “Routing” layer, as routes are developed not only in the IP network but in the various underlying networks it connects. I would expect that a document approved by the IETF would use language that the IETF consistently uses in its other documents.

Section 6 is entitled “Command format”; I take it from this that the protocol is a member of a class of command/response or command/telemetry protocols. Codes 1 and 3 (Link Accept and Link Request) are *responses* to codes 0 and 2, at least from their names. Question: if these are “commands”, what action is taken upon the receipt of the response messages - who is commanding whom to do what? The section seems to me more of a “message format” than a “command format”. 

A question regarding the multicast distribution algorithm... The development and specification of network multicast has been trying in the IETF, and is generally not obvious. The answer to this question may be inherent in 802.15.4 multicast, which I’m not familiar with. However, I’m curious. IP multicast tries to deliver a message exactly once to each member of a multicast group, and in sequence. In a mesh network, that may not be possible and in any event probably isn’t work the effort to achieve. However, a message should be provably delivered to every node in the multicast group at least once, should not be delivered unnecessarily often, and if it changes the state of the network in some way, such changes should not be reordered. How does multicast work in this network? Is it that every node that receives a message repeats it once but not on subsequent receptions, and hopes for the best? Is there an acknowledge number or bit pattern that would let a neighbor know that it had missed something?

Are integers in this protocol in “network byte order”, aka “big endian?” 

Section 8 refers to a site-local multicast address. This is not called out in the IANA Considerations as needing to be assigned. The call-out, when added, should refer to section 2.7 of RFC 4291.

Are the IP addresses used in this protocol IPv4, IPv6, or both? I’d suggest that “IP” be defined as “IPv6” or globally replaced to read “IPv6", with appropriate references to RFCs 2460 and 4291. In the RFC series, “IP” usually is a reference to IPv4 for historical reasons.

The security considerations looks at the TTL to ensure that it is exactly 255. That’s fine for unicast messages. With a multicast message, I would expect the TTL to be decremented, and the decremented TTL to be accepted. Network multicast is used to distribute network-wide parameters, if I understand this correctly.




Attachment:


signature.asc




Description:

 Message signed with OpenPGP using GPGMail