On Sep 28, 2011, at 1:25 PM, Pascal Thubert (pthubert) wrote: > Hello Mark : > > >> The majority of IP-based home networks today are neither power-constrained >> nor particularly lossy. So, while we can certainly learn from LLN >> requirements analysis, I do think the base requirements in homenet could >> turn out to be quite different, or at least a smaller and slightly different >> subset, of the overall LLN requirements. > >> Certainly, home networks have an emerging IP-based "low power and lossy" >> component in them. One could even argue that it will become dominant at some >> time in the future, but that's a leap I personally would be pretty >> uncomfortable in the group making without some very strong data to back it >> up. > > > In any case we have to consider the integration of the LLN (e.g. a Command > and Control) component of the network within the HOMENET architecture, > wouldn't you think?
Yes. > If so, there is a probably a RPL piece to the story, and the question becomes > how that piece integrates with the rest of the architecture. We probably want > to obtain a converged network, and probably would prefer to avoid running too > many routing protocols, with redistribution policies etc... which can rapidly > become nasty in terms of administration.\ > Anyway, I'd suggest that whether the home network is fully an LLN or not is > not necessarily the core if the RPL applicability discussion: > > * ROLL did not produce a routing protocol that is limited to LLNs, but a > routing protocol that is acceptable for LLNs. IOW it is not restricted to > LLNs, by far. Bummer of a name then ;-) > * RPL is designed to be simple to deploy. It inherits from mesh technologies > the traditional self-* properties which make it quite autonomic thus better > fit for unmanaged environments. > > * RPL is designed and optimized for edge (stub) networks, with one or > multiple gateway. Just like L2 mesh networks, RPL builds multilink nets > and/or subnets that are oriented towards the gateways. It is possible to > optimize traffic from/to certain destinations within the network, but the > general goal is NOT any to any optimization. As a result, it can be desirable > to have a non-RPL high speed backbone that can be a single backbone link or > that can be a more complex IPv6 backbone network running, say, a link state > protocol, when that's really needed. > > * Associated to the support of multiple gateways, RPL incorporates natively > the concept of multiple routing topologies, for instance if you want to > separate a metering network that reports to some utility with your voice and > video network. This comes with 6MAN drafts that enable to tag the packets so > as to follow the appropriate topology. > > * Finally, the brains for the routing decision is a plug in, called an > objective function (OF). So even if HOMENET inherits from ROLL for the DV > loop avoidance scheme and from 6MAN for the tagging/forwarding, the WG can > still define one or more OFs that will dictate the shape of the resulting > routing topologies. The OF is the decision maker that will, say, prefer a > high speed Ethernet over an LLN, for a given class of traffic. > > What do you think? Since you asked, *I* think that a homenet has functional overlap (what I called "at least a smaller and slightly different subset" in my email) in terms of requirements to LLNs. At first blush, it looks like RPL has lots of functionality - perhaps more than we really need for homenet, and by your own admission more than you need for LLN's - but will hold reservation on what I think best fits the bill until we see Fred's analysis, hear from others, etc. But of course what's most important is what the WG thinks, not me. - Mark > > Pascal > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
