Wednesday June 15, 2005

MLDv2 and IGMPv3

On March 31, 2005 support for MLDv2 and IGMPv3 was put back to build 13 of Nevada. Additionally support for a an API to access the new features available in the update protocols was putback. A non blogging coworker did all of the engineering work involved in this project. A group of us did the design review and myself and another engineer did the code review.

MLD (Multicast Listener Discovery) and IGMP (Internet Group Management Protocol) provide the capability to discover multicast listeners and their interests on directly attached links. MLD does this for IPv6 and IGMP does this for IPv4. The v2 and v3 aspects of these protocols is adding the support to filter based on source. Previously traffic was filtered based on its target (I'm getting a specific multicast stream). Now listeners can claim interest in only streams from a specific source (I'm interesting in getting a specific multicast stream from some source I know is good). Both MLDv2 and IGMPv3 interoperate with their earlier versions.

The API changes for the project allowed the user to manipulate filters for the groups they joined. The API RFC specifies three APIs. First of all is a Delta-Based API specified in section 5.1 of the RFC. This API allows one to specify which groups and sources one is interested in via socket options. MCAST_{JOIN,BLOCK,UNBLOCK,LEAVE}_GROUP and MCAST_{JOIN,LEAVE}_SOURCE_GROUP are the operations in this group. A previous blog entry talks a little about socket option processing and will help you find the implementations of these socket options. The second API is specified in section 5.2 of the RFC and is called the "Full-state" API. In this API there are two functions, setsourcefilter and getsourcefilter. These functions take a series of arguments which specify the pair and a mode which specified whether the source is included or excluded. The last API is marked historic. Its provides access in a manner similar to the "Full-State" API via the ioctls SIOC{G,S}IPMSFILTER. This API is specified in section 8 (appendix A) of the RFC. In addition to all of the APIs which are protocol independent section 4 describes an IPv4 specific API which has both full and delta based versions similar to the protocol independent ones.

Whew. Thats a lot of APIs for something so straightforward. Its often a blessing that the IETF community tends to iterate a lot. When successful they converge to some pretty good specifications. Historically they have kept themselves mostly to bits on the wire so they were careful to maintain backwards compatibility. Users didn't normally see this churn. But as they have gotten into APIs sometimes the churn can generate a little bit of pain. In this case the APIs layer nicely.

The putback was made up of 44 files. Besides the kernel and library changes netstat, snoop, and truss had to be modified. The first to display the filters, the second to display the new bits on the wire, and the last to display the new ioctls. If you are considering this type of protocol change its important to remember to modify snoop. The same is true of adding ioctls and remembering to update truss.

As far as library changes you can find the code in sourcefilter.c. The less evident part of making a library change in solaris is the library spec file. The one for the socket library can be found in socket.spec. This needs to be modified if you make a library change.

The kernel changes are spread over the majority of the files in the putback. A few of them (ip.c, ip6.c) havn't been opensourced yet due to IPsec issues. The main file to implement the protocol is igmp.c. Note that the MLD and IGMP protocols share a lot and are both implemented in this file. You can following the train of socket options down into the kernel directed by the opdes_t structures in ip_opt_data.c, icmp_opt_data.c, and udp_opt_data.c.