Subject: Re: (mobile-ip) Multicast support in IETF RFC 2002

From: Gerald Maguire <[email-masked]>
Date: Wed, 12 Nov 1997 23:51:37 +0100 (MET)

To take public a discussion Jun and I have been having:

    On Wed, 12 Nov 1997, Gerald Maguire wrote:

    I suggested how it can send out a report - by using the multicast
    router's address as the  source address. Thus satisfying the needs for
    the IGMP report and providing an address which certain to be valid for
    this subnet (since the multicast router send the query on this subnet
    with this as a source address).

    Chip

    In my very first message, I proposed to use the foreign agent
    care-of address instead. Mobile host will know this address when
    it registers with foreign agent. If use IGMP query's source
    address as you suggested, you may need some modification on
    mobile host. One of them is mobile host need to take out the
    source address from IGMP query and put them in its own IGMP
    report. 

    Jun

But the advantage of just taking the IGMP query's source addres is
that this works for BOTH mobile and non-mobile devices. So I only have
to change the IGMP code on my machine, I don't have to care if the
machine is mobile or not. It also works if I am mobile, whether I am
at home or away. I don't have to do any thing special.

If you used your model, then I would have to have different processing
if I am mobile or not; and if mobile, I have to have different
processing of an IGMP query if I am at home or if I'm away from home.

To implement this one only needs to modify a line of igmp.c just, this
new line sets the source address to the multicast router's
address. See TCP/IP Illustrated pg. 390, at line 238.
As per ip_ouput.c lines 216-217 (pg. 232) - if the address is
set, then it is used.
	
Note that since the rip_input function was called by the IGMP query,
it put the source address of the incoming query in a global variable
called ripsrc (at line 66 of raw_ip.c, on pg. 1054). So we can just
used this address in igmp.c at line 238!

So is there some case where changing these two lines - does not do
what we need to have done?

Chip
-----------------------------------------------------------------------------
IETF Mobile IP Working Group Mailing List - Archives:  software.watson.ibm.com
Unsubscribe:	unsubscribe mobile-ip		(as message body, not subject)
Direct all administrative requests to [email-masked]

---

From: Jun Wei <[email-masked]>
Date: Wed, 12 Nov 1997 15:14:50 -0800 (PST)

Chip

This sounds like a suggestion to IGMP implementation. 

One concern is that when a host first joins a multicast group, it
will send out an IGMP report without waiting for next IGMP query
from mcast router. The mcast router then will graft to next mcast
router until the one that can forward the requested multicast
traffic. (here we talk about initially how the multicast tree
gets bulit up). In this case, the host need to know the multicast
router's address beforehand if IGMP is implemented as suggested
above, which may not be trivial especially for mobile host.
I don't think this modification is a trivial one. 

 Jun

---

From: Gerald Maguire <[email-masked]>
Date: Thu, 13 Nov 1997 01:45:28 +0100 (MET)

Looking at ip_output.c (pg. 357) - it would appear that unless an
interface is specificed that when the IP_ADD_MEMBERSHIP occurs that it
will simply "use the interface of the route to the given multicast
address" - in which case it will simply use the address set in
imr_interface.s_addr.

If this address is INADDR_ANY, then it ends up calling rtalloc to get
a route. This can be made to determine the mcast router's address.

The handoff procedure can easily clear this variable and make sure
that as part of the registration, then sets this variable and ripsrc
to the mcast router's address.

However, I observe an even bigger problem which is that interface
specific and generic multi{} structures - may be wrong if you have
multiple interfaces. {Since the decision of which interface to use in
conjunction with this multicast address is made ONLY at the time of
the join.} Thus it looks like to make it work properly, one has to
drop and add all multicast groups - to make sure that the structures
all get rebuilt correctly.

Chip