Date: Wed, 04 Mar 2009 01:47:58 +0000 From: Bruce Simpson <bms@incunabulum.net> To: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: HEADS UP: IGMPv3/SSM: alpha code drop. Message-ID: <49ADDDCE.5000203@incunabulum.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49ADDDCE.5000203>