Yes to both.

RPL had to address multiple IOT GWs from the start, say one for the power 
utility, one for cloud access, etc... 
to address this is that it creates multiple instances which are as many logical 
topologies. By selecting the instance applied to a packet, the source or the 
first RPL router will force which GW is used.

RPL extends the hop count to include more information, including that instance 
ID. This is done by a HbH option though arguably the flow label would suffice 
to carry it should 6MAN allow that usage.

For a good Linux implementation, you may start with Unstrung on OpenWRT. More 
discussion on ROLL at this very moment.

There is also a discussion on relating  BABEL and RPL operations on ROLL and 
MANET. For the record, we have RPL running on some of the smallest routers on 
this planet. But we also have it running of the some of the biggest iron we 
have at Cisco. This is how versatile RPL can be. This is because RPL is a 
generic DV operation, designed to be instantiated by the selection of an 
objective function that will deal with link types, metrics and policies,

Cheers,

Cheers,

Pascal

> Le 3 avr. 2015 à 10:08, Steven Barth <[email protected]> a écrit :
> 
> 
> 
> 
>> I 'll note that RPL already addresses the problems the Margaret listed
>> in Dallas, in with a proposed standard doc. The shortest time to
>> Homenet is probably to explain how to use RPL at home, and that
>> probably requires only a guideline informational document...
> 
> Interesting. Does RPL fulfill the requirements for a homenet RP already: 
> supporting source-dest-routes and being autoconfiguring?
> 
> Also is there any good linux-compatible C implementation to play with?
> 
> 
> Cheers,
> 
> Steven
> 

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to