Thank you for your comments,
Le 29 avr. 2014 à 09:52, Mikael Abrahamsson <[email protected]> a écrit : > On Mon, 28 Apr 2014, Pierre Pfister 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 ? > > Absolutely, fully support. > >> 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. >> 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. >> >> Are these definitions reasonable to you ? > > I would like to not rule out the home as a multicast sender to the outside. I > agree not sending out the packets is good default behavior, but there could > be potential use-cases going forward where one would actually like the home > to be able to source multicast. Why not I guess. Border routers could be configured manually or with HNCP to allow some groups to be shared with the outside. > >> 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’’. > > You don't write this outright, so just let me ask: You don't propose that the > home speaks PIM with the ISP, right? In my view, the world the home would do > IGMPv3/MLDv2 join towards the ISP. It would then use PIM-SSM within the home > for the multicast routing. If we have to insert a static /128 route towards > each S, that might be the price to pay. Of course ! The problem would be quite easier if home and ISP could speak PIM, but the goal here is to make border routers proxy PIM subscriptions toward the ISP using IGMPv3/MLDv2 indeed. > >> 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: > > Personally I think that SM should go away, and we should only use PIM-SSM. > I'd rather see the S being sent out as service discovery messages and > discovered that way, rather than using PIM-SM to discover sources. I now read > up on BIDIR (didn't know about it before), and.. hm, well, so your proposal > is to only use shared trees within the home and nothing else? Well, it's and > idea that should be considered. Using service discovery makes sense in order to discover service sources. But in a dense sources situation, wildcard subscription (*,G) could still be useful. I think the hard part is SSM (Because it requires more knowledge about source/group location). Once SSM is supported (*,G) subscriptions would work as well. So I don’t think discarding (*,G) would make the solution easier. What I like with BIDIR is that you don’t use tunneling even if you have no idea where is the source located (which could happen quite often if the source is from an ISP). But if you do, then you can optimize the path. I have no experience using BIDIR thought (and am looking for an IPv6 implementation for Linux, if anybody has one). > >> 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 ? > > Wouldn't it make sense that the HNCP elected routing would have a PIM > priority setting that would elect it to be PIM DR on the LAN as well? It makes sense. IMHO the most complicated part in PIM bootstrapping is the message formatting and transmission. But I don’t see any capabilities or performances differences between PIM BS and HNCP. So using HNCP for election is possible. > > -- > Mikael Abrahamsson email: [email protected] _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
