Subject: Re: [MOBILE-IP] draft-ietf-mobileip-rfc2002-bis-02.txt

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 13 Jul 2000 11:42:35 -0700

Hi Charlie,

I wanted to get back on the multicast section, but sorry for the delay.

Section 4.4  on the rfc2002-bis draft is little bit confusing for
implementors--when I read it first time, I was not clear at all
on the requirements. So, I have some questions to clarify and I think
it will be helpful for the community if that section is clarified.
I haven't heard any implementation suporting multicast over the
forward/reverse tunnel yet though.

Second paragraph on section 4.4 writes:
   In order receive multicasts, a mobile node MUST join the multicast
   group in one of two ways.  First, a mobile node MAY join the group
   via a (local) multicast router on the visited subnet.  This option
   assumes that there is a multicast router present on the visited
   subnet.  If the mobile node is using a co-located care-of address,
   it SHOULD use this address as the source IP address of its IGMP [8]
   messages.  Otherwise, it MAY use its home address.

So, if a MN joins the multicast group in the visitor network and if the
FA is not a mcast router, then FA will not know about the MN's activity.

I think, that's why in the 4th paragraph it says:

   Because multicast routing
   in general depends upon the IP source address, a mobile node which
   sends multicast datagrams directly on the visited network MUST use a
   co-located care-of address as the IP source address.       ^^^^^^^^

SO, does it imply that *only* MN's using co-located care of address
can join the multicast group directly in the foreign network ?

If so, we need to clarify that in the second paragraph.

So I can see steps in case 1)i,e sending mcast directly on the visited network :

1. Multicast router forwards the packet to CN in regular multicast routing path
   as MN joins the mcast group in foreign network.

2. The CNs will send multicast packet -- Now how HA will get this packet ?
   How does the packet come back to MN ? Does it mean that HA MUST be a mcast
   router always ?  Currently it does not say so. Even if HA is a mcast router
   it has to know that MN with co-located care-of-addr has joined the
particular group  ?

 Thinking about this complicacy and providing two ways of sending multicast
 datagram seems to me complicate the whole protocol for implementation.

 I wonder, what if we restrict only one way of supporting multicast packets?

option 1)
 I understand that air bandwith is expensive and cell phone folks do not like
  tunneling too much, so what if we just provide multicast capability for
  MNs with co-located care of address only ?

 option 2)
 For multicast packets, the MN will always encapsulate the mcast packet and
 FA must provide EDS service and HA must be a mcast router. MN joins the
 multicast group over FA-HA tunnel.

 Also, I don't completely understand the following text in third paragraph
 in section 4.4 :
  Alternatively, a mobile node which wishes to receive multicasts
   MAY join groups via a bi-directional tunnel to its home agent,
   assuming that its home agent is a multicast router.  The mobile node
   tunnels IGMP messages to its home agent and the home agent forwards
   multicast datagrams down the tunnel to the mobile node.

 SO, I assume "bi-directional tunnel" above means that MN can encapsulate
 multicast packet with outer dst=HA and outer src= MN's home-addr.
 Also MN is capable of decapsulating any packets coming from HA for which
 the outer dest = MN's homeaddr and outer src=HAA.
 This seems to be not clear in the draft.

 A diagram similar to the following is helpful also:

 Datagram flowing from HA to FA forward tunnel when HA is a multicast
 router and it received a multicast packet for MN.

-------------|
|dst = COA   |
|src = HAA   |    outer IP hdr
-------------|
|dst = MN    |
|src =HAA    |    inner IP hdr1
-------------|
|dst = MCAST |   inner IP hdr2
|src = CN    |
-------------|

Now the question is how HA keeps it binding list for multicast, if N number
of MN's have joined the same MCAST group, then when HA gets a mcast packet
for MCAST, it needs to forward through different nested tunnels and/or
home network appropriately.  I assume this should be part of normal multicast
routing. I am not a multicast expert, so I don't have the proper answer.

Thanks very much,
-Samita

>
> I have the new revision prepared for RFC 2002bis.  For those who
> are interested, please have a look:
>         http://www.iprg.nokia.com/~charliep/txt/mobileip/mobileip.txt
>
> I'll probably send it in later today if there are no further
> comments...
>
> Regards,
> Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 14 Jul 2000 09:20:37 -0700

Hello Samita,

Here are my last-minute comments on your questions about multicast.

> it will be helpful for the community if that section is clarified.

I will try to think of a clarification, but right now I don't know
what it is.

> FA is not a mcast router, then FA will not know about the MN's activity.

Isn't that O.K.?  If the FA is not a multicast router, it's hard to
know how or why the FA could/should be aware.

> can join the multicast group directly in the foreign network ?

I don't think it implies this, especially if somebody wants to design
a protocol for making it happen with the foreign-agent care-of address.
If the foreign agent gets a packet for a multicast group, and if it
knows that the mobile node is in the multicast group, why shouldn't
it send the multicast packet to the mobile node?  The question would
then be how to make the foreign agent aware of the mobile node's
desire to be part of the multicast group.  That's for receiving.
For sending, one could still imagine an arrangement by which the
foreign agent sent multicast packets on behalf of the mobile node.

So, I don't believe we should make the suggested restriction.

> 2. The CNs will send multicast packet -- Now how HA will get this packet ?

If the correspondent node sends a multicast packet to a multicast
group, it goes by way of the multicast tree.  The HA may be a member
of the multicast group, and it may keep records to indicate that
the mobile node is also a member of the multicast group, but I do
not think that the correspondent node has to do anything special here.

>    it has to know that MN with co-located care-of-addr has joined the

Even if the HA is not a multicast router, the mobile node could get
multicast packets by joining the multicast group locally.

>  I wonder, what if we restrict only one way of supporting multicast packets?

That would represent a major change, and would need a lot of discussion
in the working group before it could be put into the specification.

>  multicast packet with outer dst=HA and outer src= MN's home-addr.

I think this is right, especially considering that the text was
written before RFC 2344.

>  This seems to be not clear in the draft.

I'll try to find a place to put these points.

>  router and it received a multicast packet for MN.

Unfortunately, I don't have enough time to construct this diagram
before the deadline today.  Please bring this up during IETF 48
if you believe it still isn't clear after the new explanatory
sentences I have put into the new revision.

> routing. I am not a multicast expert, so I don't have the proper answer.

There are interesting papers about this.  Look for them in previous
Mobicom conference presentations, or scan for papers by
Vineet Chikarmane, Carey L. Williamson, Richard B. Bunt, or
Wayne L. Mackrell in previous year's Mobicom conferences, or our
special issue of MONET from last year.

I'll put the newest RFC 2002bis at:
        http://www.iprg.nokia.com/~charliep/txt/mobileip/mobileip.txt
in a few minutes when I get these changes made.

Regards,
Charlie P.