> 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. [Pascal]
Same here. I do not like the idea of mapping either and I certainly hope we can avoid that. To serve on or more multiple SPs, a host needs to understand the scope associated to each SP and then learn prefixes, CIDs and stuff that are used within that scope. >From there comes the need for an abstract identifier for the scope to associate with the context option, the PIO and whatever else that gets disseminated for that SP. At the moment, the ND draft does not have that scope, and thus all information is global, and thus all must be coordinated and homogeneous between all LBRs. Which I understand is the valid issue in this thread. If the dissemination process is RPL, then the unique identifier for the scope is quite naturally the same as the instanceId, and that means that the host should see the instance ID as an abstract scope ID, even if the host is not aware of RPL per se. If the scopeID flows in the 6LOWPAN ND messages together with a TID, then redistributing the ND registrations into RPL as host routes becomes doable. I understand that RPL and 6lowpan ND wish to be able to live independently, but I still wish to see that they can also cooperate. Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
