13 Oct
2020
13 Oct
'20
12:41 a.m.
William Waites via 44Net je 12. 10. 20 ob 10:04 napisal:
How can the native part scale (beyoned 44Net)? We
can't have zillions of
join/leave messages percolating all the way up the tree because the load
resulting from processing these would become unmanageable. In the limit,
each multicast group containing two participants, we've just recreated
unicast with a far more expensive routing protocol. But neither can we
have all sessions carried in the core (or can we? are we able to
overprovision like that? maybe if we reengineer the content
distribution networks to do this... perhaps they do it themselves
already). Anyways, that's the basic trade-off (regardless of protocol
choice or acronym flavour). A partial solution is to also have a notion
of geographic scope.
Multicast happens only on local subnet. But it can be extended to other
subnets via unicast by help of PIM protocol (Protocol Independent
Multicast).
PIM supports two modes: dense and sparse mode. In dense mode a sender
floods the whole network until receivers explicitly say no (prune). In
sparse mode there is one Rendezvous Point (RP) where receivers ask to
join the sender stream.
RP does a coordination so that sender streams via unicast directly to
the receiver's subnet router, which finally multicasts to that subnet.
This way the multicast traffic is reduced on the whole network to a minimum.
RP router is a single point of failure, so there are more candidate RP
routers. And to complicate matter a bit more, there are also Bootstrap
routers (BR) to help discovering the RP.
Mikrotik is the only one among cheaper gear to have a PIM (only Sparse
mode) implementation. It is a bit clumsy but with a few tweaks it is
(from my experience so far) manageable.
73,
Janko S57NK
Anyways, just some thoughts.
73s
VE0HAK