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

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 14 Jul 2000 17:42:13 -0700

Hello Charlie,

Thanks for agreeing to put some clarifying text in the draft for the
multicast section.  Please see my comments below.

> > 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 will try to think of a clarification, but right now I don't know
> what it is.
>
> > 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.
>
> 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.
>

Yes that is true. FA does not need to know if MN has co-located COA.

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

If the mobile node uses it's homeaddr as the source address, then it
may join the multicast group in the foreign network, but it should send
packets through it's home network using reverse tunnel (rfc2344-bis)--
right ? The multicast router may not forward the packet, if the source
addres is not topologically correct.

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

 I was under the impression that packet from CN must come via HA always.
 It is not the case for multicast packets. I see your point.

> >    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  ?
>
> Even if the HA is not a multicast router, the mobile node could get
> multicast packets by joining the multicast group locally.
>
>
> >  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?
>
> 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.
>

It would simplify the protocol if we say something like the following :

1) If the MN uses home-addr as source address, then it MUST use encapsulated
   packet delivery to FA which in turn reverse tunnel the packet to the
   home agent acting as multicast router. Home agent is responsible for
   multicast packet delivery using nested tunneling through forward tunnel.

2) If the MN sends/receive multicast packets through the multicast router
    on the foreign network, then it MUST use a co-lacated COA in the foreign
    network.

> >  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.
>
> I think this is right, especially considering that the text was
> written before RFC 2344.
>
> >  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.
>
> I'll try to find a place to put these points.
>
> >  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    |
> > -------------|
>
> 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.
>
> > 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.
>
> 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.
>

Thanks for the pointers.

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

Thanks and regards,
-Samita