On Mon, Apr 28, 2014 at 6:10 AM, Pierre Pfister <[email protected]> wrote: > Hello group, > > I’m working on the homenet experimental implementation > http://www.homewrt.org/ and have been thinking on multicast support for > homenet. Encountering a few design issues, comments from the working group > could be helpful. > > This is a short version of my thoughts about the problem. I’m thinking about > writing a draft about it. But I would like some feedbacks from the group. > > > 1) Why supporting multicast. > > I think homenet should support: > - Hosts in the home should be able to join a group and receive traffic from > inside the home and from ISPs if they provide traffic for it (and the scope > allows it) > - SSM should be supported. > - It should work with multi-homing. > > Do you think these are reasonable requirements ?
Sure. However the only thing that still sort of uses multicast from the wan side is some forms of television. Regrettably the state of pim is very very very undertested and the relevant code for it needs love - pimd (what I ship in cero) is rather flaky, and pim support from things like quagga only existed, if ever, out of tree. I don't listen on the wan address. Things like openwrt compile pim out by default. (It's compiled in in cerowrt, but I'm not aware of any users) > > 2) Scope considerations. > > A basic home router supports « internal » and « external » interfaces. So > for each multicast scope, we should define the default behavior for each > case. Possibly, improved routers may support tunnels between homes or home > administration areas. Multicast is a major headache from a firewalling perspective and in multiple other regards. The cerowrt bcp38 implementation filters out list match '240.0.0.0/4' # RFC 5745 and relies on source specific routing to filter out other stuff on ipv6. > One possible default behavior could be: > - Admin-local: Block from external (optionally block from tunnels and other > home sub-areas) (Might be used to create sub-areas in the home network). > - Site-Local: Block from external (optionally block from tunnels) (Local to > geographically localized area, for connexion between multiple sites like > VPNs between homes, use a bigger scope) > - 6, 7 and 8 (Organization Local): Block from external (Organization Local > being the bigger Home-local scope, in case you own multiple homes for > instance, or distant servers connected through VPNs, etc...) > - 9 to E (global scope): Accept from internal and external links > > I think multicast packets originated inside the home must never leave the > home network. Depends on your form of multicast. If they cannot join a group on the next hop up, they won't go anywhere. > Are these definitions reasonable to you ? > > > > 3) Using PIM SM. > > I’ve been looking at PIM as a solution candidate (If you think another MRP > could be used, please tell ! :-) ). I don’t consider DM as a possible > solution. SM and BIDIR could be used. > SM would work out of the box if there was no issues with multi-homing. > Indeed, border routers have to subscribe to groups on external interfaces > when some host inside the home has interest for the group. So border routers > needs to be aware of the subscriptions inner hosts made. > > So either: > - Only a single ISP sends traffic from the outside for each group. In which > case we can use a group-to-rp mapping where every border router is a RP for > its own group. That is supported by PIM. We would need configuration (e.g. > DHCP, static) from ISPs to create that mapping. > - We want multiple ISPs to be able to send traffic for some group, in which > case a single RP should send subscription control messages to all border > routers in order to control home multicast subscriptions (That would require > modifications to PIM). > > Another issue comes when using SSM. The path (S, G) subscriptions follow is > dictated by routers’ routing tables. That works well when the source is > inside the routing domain (the home), or when there is a single border > router (and that router is the RP). When there are multiple border routers, > there are multiple default routes. We need do decide which border router to > use, and that must be consistent. We could use a group-to-rp mapping as well > here. Or a single RP could send control unicast packets to border routers > (like previously). I have a more precise description of that possibility, > but I want to keep that mail ‘’short’’. > > > > 4) Using PIM BIDIR. > > I personally prefer the BIDIR possibility. With a single RP which sends > subscription control messages to border routers (that would require protocol > specs). (*,G) would flow toward the RP and (S,G) would flow toward the > source when it is inside the home, or toward the RP when the source is > outside the home. By default, this architecture would not support path > optimization when the source is outside the home. > But: > - I imagine future home networks to be organized around high-bandwidth > link(s) (e.g. wired) attached to CPE border routers and less efficient links > (wifi, sensor networks, …). So in BIDIR, it’s not a problem receiving more > traffic on the central link, and path optimization would often not optimize > anything. > - In general, it could be useful to have a way for ISPs to say ‘I do own > these addresses’. For instance, RA’s RIOs could be used. In which case the > routes would be injected in the routing protocol, and (S,G) messages could > flow toward the correct home exit. > > The good news about BIDIR being that it works even when you don’t really > know how to route (S,G) subscriptions. Which we don’t in general when S is > outside the home. > > Does anybody know about some IPv6 BIDIR implementation we could use/patch ? > That would be very helpful !! > > > > 5) For autoconf > PIM makes use of its own bootstrapping extension. HNCP could be used as well > for the exactly same purpose (election is pretty obvious in HNCP). An > extension would be really easy do define. What do you think ? > > > Thank you for your comments, > > Pierre > > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
