Hi Randy, RFC8180 proposes some configurations so vendors can bootstrap the network, this is for example the fact that a minimal cell exists. The content of EBs is defined in the 802.15.4 spec and as long as an implementation fulfills the standard a vendor node should be able to handle EBs. IEs in the EBs announce the network configuration and a vendor may use the default values or define their own ones. Other vendors should parse that information and configure the network accordingly so they interop. RFC8180 is an enabler for the bootsrap as those nodes at least share the same communication cell and can initiate the exchange. This information is announced in the EB.
When a network is not using RPL the Join Metric contains a depth counter that nodes use to select a candidate parent to join. This policy is defined in the IEEE802154 std and hence a node should be able understand it. If a vendor changes that policy, as far as I know, there is no way to signal it and then the network will behave in an unexpected manner by the other node. so answering your question, it is possible that two vendors implement a different join metric announcement and selection policy which can lead to an unexpected network topology but this does not mean that the networks won't interoperate. regards Xavi Missatge de Turner, Randy <[email protected]> del dia dl., 2 de jul. 2018 a les 16:20: > So there are no known interop issues with non-RPL minimal deployments if > different vendors choose their own EB policies? > > Thx, > R. > > > ------------------------------ > *From:* Xavi Vilajosana Guillen <[email protected]> > *Sent:* Monday, July 2, 2018 9:01:23 AM > *To:* Turner, Randy > *Cc:* tisch > *Subject:* Re: [6tisch] 6TiSCH Minimal Spec > > Hi Randy, > > thanks for your comment! When RPL is used, the EBs use the Dagrank(rank) > as join metric. In this way we match the routing topology with the timing > topology. When RPL is not used, there is no such need as the join metric is > only based in a depth counter. When a node has not acquired a rank, it may > have a default value for it. If the node uses that default value to send > EBs may cause some incosistencies in the time source structure. This is the > reason for such an indication. > > When a node is not using RPL, minimal does not mandate any particular > behaviour, the node may have joined the network and can use EBs according > to the particular network configuration (period, etc..). > > regards > Xavi > > > > > > > > > Missatge de Turner, Randy <[email protected]> del dia dg., 1 de > jul. 2018 a les 21:55: > >> >> >> Hi Guys, >> >> >> >> In RFC 8180, section 6.3 “When to start sending EBs”, there is guidance >> about when a node using RPL should start sending EBs. >> >> >> >> Should there be a prescribed “When to start sending EBs” language if a >> node is NOT running RPL ? (just to avoid an invalid assumption) Or is this >> in another section, and if so, shouldn’t this text live in this section? >> >> >> >> Thanks! >> Randy >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > > *Internet Interdisciplinary Institute (IN3) Professor* > (+34) 646 633 681 > [email protected] <[email protected]> > http://xvilajosana.org > http://wine.rdi.uoc.edu > Parc Mediterrani de la Tecnologia > Av Carl Friedrich Gauss 5, B3 Building > 08860 Castelldefels (Barcelona). Catalonia. Spain > [image: Universitat Oberta de Catalunya] > > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 [email protected] <[email protected]> http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya]
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
