On 07/ 7/10 12:31 AM, Pascal Thubert (pthubert) wrote:
RPL expects a different instance for different 2 service cies. In the simplest case, we'd end up with 2 LBRs, one serving the Electrical Company and one the ISP. Each LBR spawns its own DODAG. Some relay routers in the home belong to both instances to support both the electric lights and the security monitoring. So packets are tagged to follow the right topology. Whatever a LBR injects is contained within the scope of the instance it injects it into. It appears that the CO dissemination would benefit from the same model. Just like we can map the abstract TID in the RPL path sequence, would there be a way to define an abstract ND context ID that could map into the RPL instance ID? It appears that such context ID could help scope the dissemination process in ND.
The RPL instances seem to assume that at least all the routers have a well-defined way to map a packet to/from a host to a particular instance. That mapping table seems like a critical piece of configuration information that need to be distributed for RPL.
If one wanted to have different compression contexts for 6lowpan for different RPL instances, then all of that mapping table would have to be distributed to each host, to ensure that the compression context that is used matches the instance that RPL would use. This sounds extremely brittle, because if there is any mistake e.g., due to some hosts having a mapping table which is out of date, the effect would be packets that can not be correctly decompressed.
Sounds like a bad idea to me. Erik _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
