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.
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.
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.
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?
--
Mikael Abrahamsson email: [email protected]
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
