[Xorp-users] IGMP/PIM question ?

[Vikram KAUL]

Thanks for your prompt responses. My comments interspersed.

pavlin>However, if I understand correctly your question, you want to
pavlin>influence the choice of which router reacts to IGMP Join messages,
pavlin>and this choice should be a function of the receiver's address.
pavlin>This is not how the IGMP and PIM-SM protocols operate, so most
pavlin>likely you won't be able to do it even with source code modification
pavlin>(the answer depends on the details about what exactlty you need to
pavlin>achieve).

I took a cursory look at the code. Specifically, 

In igmp_proto.cc   in   Mld6igmpVif::igmp_process(...)

If right away, a check for source address is done as follows...

   // Only accept my own queries, neglect all others

    if (!(mld6igmp_node().is_my_addr(src)))
	return (XORP_ERROR);

then all IGMP messages from other nodes/routers can be neglected. Of 
course this is not what the protocol is supposed to do, but I am merely 
looking at all alternatives. Because if this check, the procedures for 
selecting/electing IGMP Queriers will not happen and all nodes will be 
IGMP Queriers only responding and taking care of 'themselves'

Similarly, 

In pim_proto_hello.cc   in    static bool pim_dr_is_better(...)

could be made to return "false" all the time so the initial selection of 
this node/router as the designated router for PIM Join/Leaves is 
maintained. 

These two mods, in essence, should make each node/router 

A) An IGMP Querier taking care of only itself 
B) A Designated Router taking care of only itself

It is almost like reverting back to old times when Quering and DR was 
shared by the same router.. except this is much more drastic

pavlin>
pavlin>Below are the issues with IGMP and PIM-SM reacting as a function of
pavlin>the receiver's address:
pavlin>
pavlin> * In case of IGMP, the adjacent routers need to elect the IGMP
pavlin>   Querier. The Querier is elected per LAN and the router with the
pavlin>   lowest IP address on the LAN is the winner. Though, from PIM-SM
pavlin>   perspective you shouldn't care which router is the IGMP Querier, so
pavlin>   the IGMP Querier choice shouldn't impact you.

 See above

pavlin>
pavlin> * In case of PIM-SM, the adjacent routers need to elect the
pavlin>   Designated Router. The DR is elected per LAN, and the election is
pavlin>   a function of the routers' IP addresses and their DR priority
pavlin>   (configurable by the PIM-SM dr-priority configuration
pavlin>   option). Only if a PIM-SM router is the DR for the LAN, it will
pavlin>   take into account the IGMP Join event to initiate the PIM-SM Join
pavlin>   message.

Once the IGMP messages from any other node/router other than self have 
been neglected (above hack in igmp_proto.cc), then the DR will look at 
IGMP Join events from itself alone. 

pavlin>
pavlin>   The fundamental problem here is that the IGMP and PIM-SM
pavlin>   protocols do not track the IP address of the multicast
pavlin>   receiver. In other words, IGMP and PIM-SM care only if there is
pavlin>   a multicast receiver for a particular multicast group, but they
pavlin>   don't care about the particular IP address of the receiver.
pavlin>   Hence, when the IGMP module detects an IGMP Join event, it tells the
pavlin>   PIM-SM module about the joined multicast group, but it doesn't
pavlin>   tell anything about the receiver's address.

I understand the functionality of the protocols as they are supposed to be 
used. I am merely experimenting with them and was wondering if I could use 
the current implementations in XORP (of course, after some mods) to 
achieve my objectives.

pavlin>   One of the reasons IGMP and PIM-SM cannot track the receivers'
pavlin>   addresses is because the IGMP host protocol uses IGMP Join
pavlin>   suppression: if there are two or more receivers on a LAN for the
pavlin>   same multicast group, only one of the hosts originates IGMP Join
pavlin>   messages.
pavlin>

Unfortunately, the above mods will eliminate that supression. But I am 
willing to give something to get something in return. Of course, a more 
careful look into the implementation could guide me into making (or at 
least think of making) other mods which have minimal impact on the 
protocols. 

What is your take on whether I could get what I want by doing the above

regards..
Vikram