[Xorp-users] IGMP/PIM question ?

[Vikram KAUL]

FOlks,

  A follow up on an old thread (see below). I am still having trouble 
getting something accomplished which I thought would be fairly 
straightforward. Here goes..

  In essence, I want to be able to run PIM (however ineffective it might 
be) in an ad-hoc network where each router is a host as well. As a simple 
setup, consider R1, R2, R3, R4 and R5 in a simple chain

  The config.boot is fairly simple on all 5 nodes, (it is the same 
actually) with PIM and IGMP running on the single interface.

  R4 is configured statically as the RP and XORP is running on all nodes.

  I have made a couple of changes in the XORP mld6igmp module code :

- Only local IGMP messages are handled in mld6igmp_process()
- Do NOT ignore self queries in mld6igmp_membership_query_recv

   This enables the router to act as the primary responder to receiver 
applications

  A couple of changes in xorp PIM module code:

- Always return 'false' so that router is DR in pim_dr_is_better()
- Only send PIM register if source is self in signal_message_wholepkt_recv

What the two sets of changes should allow is that when a 
receiver-application is started on R1, it should send a PIM join towards 
R4.
When a sender-application is started on R1, only it should send a PIM 
register towards R4

When the receiver application is started, it adds MFC entry (S,G) for 
itself, but does not send a PIM Join towards R4 for which it has a unicast 
path available and ready. Subsequent kill and restarts of the 
receiver-applications merely add_memberships and delete_memberships, but 
no PIM joins are initiated from R1 towards R4 via R2 and R3

There are issues with the register as well, but let me resolve this one 
issue at a time.

If someone needs, I could send in logs, etc of the debug statements and 
outputs of "show pim mfc" etc

Please advise

regards..
vikram





---------- Forwarded message ----------
Date: Tue, 23 May 2006 11:58:43 -0700
From: Pavlin Radoslavov <pavlin at icir.org>
To: Vikram KAUL <vkaul at research.telcordia.com>
Cc: Pavlin Radoslavov <pavlin at icir.org>, xorp-users at xorp.org
Subject: Re: [Xorp-users] IGMP/PIM question ?

> 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'

Yes, modifying the above code will have impact on accepting the IGMP
control messages by XORP.

However, this modification won't have impact on the IGMP host-side
implementation inside the kernel. This is where the IGMP Join
suppression happens. Hence, even if you reject the IGMP Queries and
Membership Report inside XORP, they will still be processed inside the
kernel. The processing of the IGMP Membership Report messages inside
the kernel may trigger the IGMP Membership Report suppression (if
there are 2+ receivers on the same LAN).
As a result, you may never see the IGMP Join event by multicast
application running on the local host.

> 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.

Yes, the above modification inside PIM can make each PIM-SM router
believe it is the DR, but then you have to be very careful if there
is a sender with 2+ PIM-SM routers on same LAN. Each of the routers
will think it is the DR and will eccapsulate same multicast data
packet in PIM Registers and unicast it to the RP.
As a result, you will see duplicated packets from the sender.

> 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.

Unfortunately, those mods won't eliminate the suppression problem,
because as I mentioned above it happens inside the kernel, and you
cannot disable it by userland programs.

Also, they won't eliminate the PIM Register encapsulation issue.
Though, if you always switch to the shortest path (to the sender)
after the first data packet, then the PIM Register duplicated packet
will happen only when a new sender becomes active (until the SPT
switch to that sender is completed).

Pavlin