HEADS UP: IGMPv3/SSM: alpha code drop.

[Bruce Simpson]

Hi all,

I am making patches available against 8-CURRENT to do IGMPv3 and Source 
Specific Multicast in the IP stack:
    http://people.freebsd.org/~bms/stage/igmpv3/

    At the moment, the patches are extracted from Perforce, so may need 
some rejigging of patch's -p option. I would hope to post step-by-step 
instructions as time permits, however, others are welcome to join in and 
contribute how-tos like this.

    This is considered alpha quality code at the moment. It has seen 
some testing in a QEMU environment. Things which are known not to be 
tested, although believed correct, include response to a Group-Source 
query, and backwards compatibility mode for IGMPv1/v2 multicast routers.

    Whilst there have been similar efforts from KAME and others, it 
wasn't possible to incorporate them in FreeBSD due to divergence in SMP 
implementation. Most of the work involved in this project was to do with 
fine grained locking, and layering the state machines in such a way that 
the locks could be untangled and taken in the right order. The code is 
also believed to do the right thing with respect to VIMAGE.

    From an architectural standpoint, the most important wide-ranging 
change that this makes to the IPv4 stack in FreeBSD, is the change which 
takes the IN_MULTI_LOCK() out of the ip_output() and ip_input() paths. 
Filtering of inbound multicast traffic is pushed up to the transport 
protocol layers (RAW, and UDP; SCTP and TCP drop multicast traffic.) The 
rationale is that if you are running an up-to-date multicast capable 
network, IGMPv3 will ensure that you only receive the traffic your hosts 
requested anyway, and bottom half IP has no business taking socket-layer 
locks.

    The other win for IGMPv3 from a user standpoint is the 
retransmission of the control traffic. Whilst multicasting over lossy 
and wireless networks has issues of its own, retransmissions of the 
control traffic insulate the routers and endpoints somewhat from such 
loss. Also, IGMPv3 plays nicer with switched networks and smart switches 
-- it's easier for switches to snoop IGMPv3, as only one multicast group 
address is now used for IGMPv3 control plane traffic -- and it is easier 
for administrators to spot what's going on, as they need only sniff one 
group address.

    From the kernel point of view, one major assumption made by this 
code is that kernel consumers will never request source-specific 
memberships. If this functionality is required, it's easy enough to add 
it, as 'struct in_mfilter' is used to represent the SSM filter sets 
using RB-trees as a disjoint-set data structure.

    in_addmulti() and in_delmulti() are implemented as compatibility 
shims only to the new KPIs. Currently the carp(4) code relies on them.

I'll be pushing some of the userland changes in shortly. My intention 
would be to merge this to HEAD sometime within the next week or so, this 
is long overdue, and needs to go in, as it brings us up to date with 
Windows and Linux on the implementation.

Unfortunately, whilst I have an automated regression testing suite in 
existence for the on-the-wire IGMPv3 protocol behaviour, I can't run it 
in simulation due to a strange issue where getty doesn't seem to work on 
QEMU's emulated uart interface. Any help to debug that would be greatly 
appreciated.

This work is being funded by a 3rd party, and is the culmination of a 
long development cycle.
Feedback is very welcome.

thanks,
BMS