Subject: [nemo] new draft submitted about NEMO RO

From: "Jongkeun Na" <[email-masked]>
Date: Mon, 3 May 2004 15:43:00 +0900

Hi all,

Just to inform you that we've submitted a new draft on the route
optimization. I don't know why that draft was not appeared in this mailing
list. Anyway, any feedback from you all is welcomed. Thanks.
http://www.ietf.org/internet-drafts/draft-na-nemo-path-control-header-00.txt

/Jongkeun

---

From: "Jongkeun Na" <[email-masked]>
Date: Mon, 3 May 2004 15:43:00 +0900

Hi all,

/Jongkeun

---

From: Greg Daley <[email-masked]>
Date: Tue, 04 May 2004 11:07:21 +1000

Hi Christophe (and the other authors),

Thanks for producing this document!

The principles are good (i've only been able to
skim through though).

I have some comments regarding multicast routing protocols,
though.

Please correct me if I'm wrong, but it seems that in the
draft you indicate that routing protocols don't need to
be run on the local routers or the MRs.

While this is indeed correct, there is the possibility
that an MR could run a multicast routing protocol
between itself (on its downstream interfaces) and its
local routers, as if it were a router on the fixed Internet.

Certainly, the local fixed routers don't need only to be
proxies.

The requirement for proxying arises only from the discontinuity
of trust between visiting MRs and the network which hosts them
(the access network or superior NEMO).

In this case, the visiting MR still needs to run MLD proxying to
the visited network in order to get route optimized (Remote
Subscription) service.

Within its own network, it may be possible to propagate
routing information either from the home network, or created by
proxying to the visited network, acting as a multicast border
router for this information.

This information could be passed to all fixed routers within the
NEMO, although visiting mobile routers wouldn't be able to
receive such messages since they're not in the same routing domain.

This would give some flexibility as to where the MR sources its
traffic (from visited or home networks), without requiring changes
to how multicast routing is configured on non-mobile routers.

Is it worthwhile to indicate this possibility in the document or
an appendix?

Please let me know what you think.

Greg

Christophe Janneteau wrote:
> Hi All,
> 
> Just to inform you that we have submitted a new I-D on the support of IP 
> multicast for mobile networks. The proposal relies on the use of the 
> MLD-based multicast forwarding mechanism (from magma WG) inside the 
> mobile network.
> 
> I was expecting the draft to be announced on the NEMO mailing list too, 
> but it was not...this is why I am sending this email now.
> 
> Thanks
> Christophe
> 
> ------------------------------------------------------------------------
> 
> Subject:
> I-D ACTION:draft-janneteau-nemo-multicast-mldproxy-00.txt
> From:
> <[email-masked]>
> Date:
> Wed, 28 Apr 2004 15:29:14 -0400
> To:
> <[email-masked]>
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: IPv6 Multicast for Mobile Networks with MLD-Proxy
> 	Author(s)	: C. Janneteau, et al.
> 	Filename	: draft-janneteau-nemo-multicast-mldproxy-00.txt
> 	Pages		: 13
> 	Date		: 2004-4-28
> 	
> This document addresses the problem of delivering IPv6 multicast
>    traffic to nodes inside a mobile network. An approach based on the
>    deployment of "MLD-based Multicast Forwarding (MLD-proxying)" [1]
>    in the mobile network, combined with the use of MLD [2][3] between
>    the mobile router (MR) and the visited network, is proposed. Such a
>    configuration allows multicast support for mobile networks, without
>    the need to run a multicast routing protocol. In addition of being
>    simple to implement and deploy, this approach provides global
>    mobility in the Internet, and optimal multicast routing with nested
>    mobile networks, while optimizing network and radio resources. This
>    document does not specify new protocols, nor extensions to existing
>    protocols.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-janneteau-nemo-multicast-mldproxy-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-janneteau-nemo-multicast-mldproxy-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-janneteau-nemo-multicast-mldproxy-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: Greg Daley <[email-masked]>
Date: Tue, 04 May 2004 11:07:21 +1000

Greg

---

From: Christophe Janneteau <[email-masked]>
Date: Tue, 04 May 2004 11:57:13 +0200

Hi Greg,

Thanks a lot for reading the draft and commenting on it.

> be run on the local routers or the MRs.

Yes, in the draft we say that it is possible to route multicast packets 
inside the moving network, without running a multicast routing protocol 
internally, by using MLD-proxying (from magma WG).

In the introduction, we also briefly mention another approach where 
fixed routers in the moving network run the same multicast routing 
protocol as the routers in the MR's home network, so that multicast 
signalling can take place over the MRHA tunnel.

> the visited network in order to get route optimized (Remote

Exactly, I agree. A multicast routing protocol can be run inside the 
moving network. In this case, the MR has basically two possibilities in 
hand:

1) behave as a regular multicast router and exchange multicast 
signalling with its home network over the MR-HA tunnel. Of course 
routing is not optimized in that case.

OR

2) Interact with the multicast router (AR) on the visited link, in order 
to optimize the routing path. Because it is possible that MR and AR do 
not run the same multicast routing protocol, and also mainly because of 
the trusting issue you mentioned, it is generally not possible for MR 
and AR to exchange multicast routing signalling directly. On the other 
hand MLD protocol can be used by MR, to inform AR about the multicast 
groups it wants to receive traffic for. MR should then acts as a 
multicast _gateway_ to "translate" group subscription received on its 
ingress interface (with the routing protocol) into MLD reports on its 
egress interface towards AR.

For the version 00 of the draft we exlicitly avoided going to deep into 
2) in order to stick to the simplest concept first. Our intention was to 
present a simple approach that would base only on well-known and 
specified mechanisms. This is why we focused only on the simplest form 
of multicast _gateway_ to be placed on MR that is a MLD-proxy mapping 
MLD into MLD (as specified in magma WG). More complex form of gateway 
would map routing protocol into MLD.

Is 2) what you have in mind?

> to how multicast routing is configured on non-mobile routers.

I agree. This provides flexibility, at the cost of deploying a more 
complex function on the MR, the border router/gateway.

Another aspect to consider is the size of the moving network and the 
additional cost introduced by deploying a multicast routing protocol 
internally. In not-too-big moving network, running MLD-proxy on internal 
fixed routers inside the moving network may be more advantageous that a 
multicast routing protocol.

> Is it worthwhile to indicate this possibility in the document or

Yes, you are right we should have a paragraph on this in future update.

Thanks,
Christophe

---

From: Christophe Janneteau <[email-masked]>
Date: Tue, 04 May 2004 11:57:13 +0200

Hi Greg,

OR

Thanks,
Christophe

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 7 May 2004 15:00:20 +0900

To all draft authors,

Note that individually submitted drafts don't get announced on the nemo
WG list if you don't **EXPLICITLY** ask the secretariat to do so.

Thierry.

On Mon, 3 May 2004 15:43:00 +0900

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 7 May 2004 15:00:20 +0900

To all draft authors,

Thierry.