Subject: Re: [nemo] nemo basic support ptotocol draft.

From: Greg Daley <[email-masked]>
Date: Thu, 26 Jun 2003 09:50:47 +1000

Hi Muhammad,
(Cc: Nemo).

Muhammad Ali Malik wrote:
> Hi Greg
> 
> -----Original Message-----
> From: Greg Daley [mailto:[email-masked]]
> Sent: Wednesday, June 25, 2003 11:09 AM
> To: Muhammad Ali Malik
> Subject: Re: [nemo] nemo basic support ptotocol draft.
> 
> Hi Muhammad,
> 
> Muhammad Ali Malik wrote:
> 
>>          Hi Greg
>>
>>This means that mobile network node (MNN) should request MR, if it
>>wants to join any multicast group. Even with multicasting, all message
>>From MNN to CH will have to travel on bi-directional tunnels.
> 
> 
> The MNN has to join the group on its AR which may or may not
> be an MR.
> 
> Multicast routing could be run on the NEMO,
> over the tunnel, but the packet flow is
> unidirectional for client multicast traffic.
> 
> Can u please elaborate it. What do u mean that the packet flow is
> unidirectional for client multicast traffic.

If we limit the discussion to only multicast clients:
those hosts consuming multicast content, without
generating any themselves, then the multicast traffic
either originates on the NEMO (in which case it is handled
by local multicast routing protocols) or is from the fixed
network.

There may be one or more multicast clients listening to
this traffic on the NEMO, though no multicast packets
are forwarded from these hosts to devices on the fixed
network: Only routing information is sent off-NEMO
in order to ensure that the MR and ARs within the NEMO
receive multicast streams to forward to their MNNs.

The traffic is flowing toward the hosts on the NEMO.

If there is a low-latency requirement in receiving the
data stream, then the MR could request it from the
visited access network using MLD/IGMP (although how the
MR would know which multicast groups to do it for would
be difficult to determine).

> So this means that even after (MNN or MR) joins the multicast group, we
> cannot avoid the tunneling.

No, not actually with the existing model (tunnel from
MR's home network).

It is possible to conceive that the MR could get service
from the visited fixed network, although this is
not supported in either current mobile-ip or nemo.

If we look at the other side of the issue:

For multicast traffic sources on the NEMO, there is
some significant benefit to sending the traffic over a
tunnel to the home network (of the MR or the MNN) in any case,
in order to avoid ingress filtering issues in the visited
access networks.

We do not want the source address to change with multicast
sources (because of source-specific multicast), so
reverse tunneling of multicast traffic generated from a
mobile device (like an MNN) looks likely.

(unless we can come up with a way of handling this issue as well).

Greg

---

From: Greg Daley <[email-masked]>
Date: Thu, 26 Jun 2003 09:50:47 +1000

Hi Muhammad,
(Cc: Nemo).

Greg