Hi Ole > we (as in homenet) do not want to require host changes.
And when hosts get smarter we (as in people living in homes) should benefit from it. The case of plain hosts was long debated but it would have overloaded the specs quite a bit. What we have so far: The backbone router proxies ND between a L2 backbone and one or more MLSN extensions; this allows a plain (classical) host connected to the backbone to transparently reach devices that are located over the MLSN. Things get touchy if we want to support the case of a plain device that would attach deep into the MLSN. You will not find that support specified in current RPL or 6LoWPAN specs. There's a good start though since RPL is designed to transport the material that is required by the leaf router to build RAs, so for the purpose of forming an address we can make believe that the plain host is really connected to the subnet. But the question is how the formed address can be DADed and routed. In the absence of an explicit and maintained registration, the attachment router/switch has to snoop and then proxy, either as an ND registration or as redistribution into the routing protocol; If the device as a unique, P2P connection with the router, then we can reuse what we learnt in SAVI to maintain states in the router on behalf of the plain host. If the device is connected to multiple routers and/or the device is mobile and changes that point(s) of attachment over time, things can get a lot messier. > I also think the issues with flooding ND has been explored in RFC4903. Thanks for pointing this. RFC 4903 explores a number of aspects, not just ND, and in particular, TTL and link scope multicast. Specifically focusing on ND, the scope and propagation of multicast already required a new protocol. RPL started as an ND extension if you care to browse the early drafts. The work that I listed below addresses for a large part the problem of ND over MLSN, yet does a limited job for generic link scope multicast. Then again there is a good start with the optimized flooding with trickle that is good for all nodes and all routers, and a support for a multicast tree along the RPL DAG for generic multicast. Cheers, Pascal On Oct 10, 2011, at 9:33 , Pascal Thubert (pthubert) wrote: > Hi Ole: > > I think you're getting closer and closer to the models that were > discussed in RPL, 6LoWPAN and Autoconf. > > There are several components to the solution that was proposed there: > - capability to register an IPv6 address using ND extensions > - capability to extend a subnet over multiple hops (RPL DIO prefix > option) > - capability to redistribute ND registration into the MLSN routing > protocol > - capability to use the ND registrar (and/or) the routing protocol for > DAD > - capability for the registrar to proxy ND over a backbone in order to > interact with classical ND clients > > See: > http://tools.ietf.org/html/rfc5889 > http://tools.ietf.org/html/draft-ietf-6lowpan-nd > http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router > > cheers, > > Pascal > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Ole Troan > Sent: lundi 10 octobre 2011 00:38 > To: Erik Nordmark (nordmark) > Cc: [email protected] > Subject: [homenet] Multilink subnet routing (MLSRv2) > > Erik, et al, > > to expand on the ideas I presented on MLSR (or rather MLSRv2 as it > hasn't really been described anywhere) as a method for numbering a > routed home. please let me be clear that I'm not convinced this is a > good idea. i.e. why not just get < /64? > I do think we could get something working though. > > routers can be in an arbitrary topology. all routers running a routing > protocol. > the site prefix (/64) is either advertised in the IGP with a new LSA > or proxying of RA messages is done (split horizon). > a router advertises the same /64 prefix (in a PIO) on all of its > interfaces. L bit is 0. > > the link model here is that all hosts are off link from each other. > link-local scope is restricted to only the physical link. multicast > link-local scope as well. > > a host uses SLAAC (or DHCP) to create an address, then does DAD as > normal. the first hop router uses it's routing topology database to > check for conflicts. similar mechanisms described in SAVI are used to > glean address information from the host. the SAVI binding database is > then used to inject host routes into the IGP. > > this requires no flooding of ND, or any other changes to on-link > protocols for loop detection. no changes in hosts either. > only downside is that it requires a host to have sent a packet of some > form for the SAVI binding to be initiated. > it might also be possible to support host mobility with the home with > this mechanism. > > cheers, > Ole > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
