{6lo is CC'ed to close this question up, but Reply-To: set to 6tisch, as
there isn't anything that is not 6tisch specific left at this point}I have just posted: draft-richardson-6tisch-join-enhanced-beacon https://datatracker.ietf.org/doc/draft-richardson-6tisch-join-enhanced-beacon/ The diff isn't very interesting, as it's mostly a forklift upgrade. This is the result of ongoing discussion to make the zero-touch and one-touch join processes work together, and to achieve a level of interoperation such that a zero-touch capable device, which has received a one-touch, could actually recognize that it needs to do zero-touch. Further, we are trying to accomodate both one-touch and zero-touch bootstrap using both pledge initiated communications (the one-touch preference), and Join Registrar/Coordinator initiated communications. The network shall know which way it will operate, and the network will announce this in the proposed enhanced beacon. (ENHANCED. I hope I stamped out all the occurances of that other E-word, which I will not write here) This text could go into 6tisch-minimal-security, or it could be a seperate document. It would have been nice to put it into 6tisch-minimal; but I sure hope that ship has sailed. Maybe it should Update that? The R flag is for host-operation of nodes which would otherwise want to listen for a multicast Router-Advertisement, or initiate one with a multicast RS. It is hard for me to construct a scenario where the R bit would be zero, and yet the device is alive enough that it thinks it ought to send beacons. It could be that some networks do not wish to support attachment of leaf nodes to all routers though. {previous paragraph probably belongs in document?} The core is: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD-XXX |J|I|R| R E S V | network ID | +-+-+-+-+-+-+-+-+-+-+-+---------+ | | network ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | network ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ J : the Join Proxy flag is set if the sending node will operate as a Join Proxy according to {{I-D.ietf-6tisch-minimal-security}}. I : the Initiate Join flag is set if this network supports pledges initiating the join process themselves according to {{I-D.ietf-6tisch-minimal-security}}. If not set, then the pledge should do an NS DAD operation ({{RFC6775}} section 4.3, explained in {{I-D.ietf-6tisch-dtsecurity-secure-join}}) and then remain silent, to wait to be contacted. R : the Router Advertisement flag is set if the sending node will act as a Router for host-only nodes that need addressing via unicast Router Solicitation messages. network ID : this is an opaque 16-byte identifier that uniquely identifies this network, potentially among many networks that are operating in the same frequencies in overlapping physical space. In a 6tisch network, where RPL is used as the mesh routing protocol, the network ID SHOULD be constructed from a SHA256 hash of the DODAGID of the network. The result will be a 32-byte hash, and the lower 16-bytes should be used. {oh. I show only 8 bytes of network-ID in the picture. Oops. I will grow the diagram} -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
