Subject: [[email-masked]: FW: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt]

From: Eun Kyoung Paik <[email-masked]>
Date: Wed, 2 Jul 2003 18:53:01 +0900

Hi,

Thank you for sharing your experiments.
It seems that you did a lot.

While I read this draft, I found an interesting scenario in Figure 5.
Could you explain the example situation that will meet the scenario in Figure 5 ? 
I am curios what the role of HA in the mobile network is.

And I have another question on the implementation of nested mobile networks.
For example, let's think about following topology.

Internet
   |
AR
   |
Parent MR
   |
Child MR

In the figure, Parent MR may autoconfigure its CoA after it listens RA of AR.
Then, Child MR may autoconfigure its CoA after it listens RA of Parent MR.
After that, if Parent MR listens Child MR's RA, 
Parent MR configures new CoA according to Child MR's RA ?
If it happens it would be wrong CoA 
since Parent MR have to connect to the Internet through AR.
I wonder if you encountered such a problem while you implemented.

Regards,
Eun Kyoung

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Friday, June 27, 2003 12:09 AM
> To: IETF-Announce:
> Cc: [email-masked]
> Subject: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: Laboratory and 'Field' Experiments with 
> IPv6 Mobile 
>                           Networks in Vehicular Environments
> 	Author(s)	: H. Lach et al.
> 	Filename	: draft-lach-nemo-experiments-overdrive-00.txt
> 	Pages		: 10
> 	Date		: 2003-6-26
> 	
> This document gives a short high-level overview of several
> practical experiments performed with mobile networks using Mobile
> IPv6-based NEMO extensions in the context of the IST OverDRiVE
> project.  Laboratory experiments include simple and nested mobile
> networks in a pure IPv6 environment while 'field' experiments
> demonstrated continuous IPv6 vehicular connectivity over two
> publicly deployed IPv4 networks: 2.5G (GPRS) and Wireless LAN
> 802.11b deployed around and inside a metropolitan area.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lach-nemo-experiments-ov
erdrive-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-lach-nemo-experiments-overdrive-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-lach-nemo-experiments-overdrive-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.

----- End forwarded message -----

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 02 Jul 2003 12:21:18 +0200

Eun Kyoung Paik wrote:
> Hi,
> 
> Thank you for sharing your experiments. It seems that you did a lot.

Thanks for appreciation.

>  Could you explain the example situation that will meet the scenario
>  in Figure 5 ? I am curios what the role of HA in the mobile network
>  is.

Having a Home Agent inside a mobile network allows for Mobile Nodes to
move around inside the mobile network, or outside.  Some terminology
calls those nodes 'LMN' or 'VMN'.

In the particular context reported in that draft, an example situation
is the following: there is a mobile network deployed in the car; there
is a tablet PC at the right of the wheel giving driving directions; the
tablet PC is also used by the driver to open the window on the roof.  At
some point in time, driver gets off the car, takes the tablet PC with
her and goes somewhere.  At some point in time, she realizes she forgot
the window open, so use that tablet PC to remotely close that window.  A
possible implementation of this scenario to work is to have a Home Agent
in the car mobile network to take care of the absence of the tablet PC.

Of course, that is not the only example situation and it is easy to come
up with a large set of example situations where a Home Agent in a mobile
network is needed.

> And I have another question on the implementation of nested mobile 
> networks. For example, let's think about following topology.
> 
> Internet | AR | Parent MR | Child MR
> 
> In the figure, Parent MR may autoconfigure its CoA after it listens 
> RA of AR. Then, Child MR may autoconfigure its CoA after it listens 
> RA of Parent MR. After that, if Parent MR listens Child MR's RA, 

In this particular configuration, I do not think that Parent MR
configures a CoA based on the Child MR RA.  There are two reasons for that.

One is that according to the stateless autoconfiguration mechanisms a
router will not autoconfigure an address on an interface based on
received RA's.  Parent MR is a router, so.

The other is that Child MR is, in fact, visiting the network of Parent
MR; when a MR is visiting, it acts as a host on its egress interface,
not as a router.  Thus it will not send RA's on its egress interface if
it is not at home, so Parent MR does not get RA's from Child MR.

I guess I have it right that way...

> If it happens it would be wrong CoA since Parent MR have to connect 
> to the Internet through AR. I wonder if you encountered such a 
> problem while you implemented.

We have encountered some problems with having a Home Agent placed in a
mobile network, indeed.  For example, there is a configuration named
"cross-over" tunnels, reported in section B.6 of
draft-petrescu-nemo-mrha-02.txt
But that problem is not related to the way routers configure their
addresses.

There is also a widely acknolwedged problem of "disconnected" operation
that was mentioned very early.

Have you encountered some similar problems?

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 02 Jul 2003 12:21:18 +0200

Thanks for appreciation.

Alex
GBU

---

From: Eun Kyoung Paik <[email-masked]>
Date: Thu, 3 Jul 2003 14:59:18 +0900

Thank you for your kind reply.
Please see inlines. 
> received RA's.  Parent MR is a router, so.

Then, how MR's egress interface configures its CoA 
when it moves into a foreign link ?
Doesn't it need RA from foreign link ?  

> it is not at home, so Parent MR does not get RA's from Child MR.

I wonder if parent MR's egress interrface listen the RA of
child MR's ingress interface.
(Child MR's ingress interface may broadcast its RA for its VMNs.)

And how can we distinguish egress interface from ingress interface physically ?

> Have you encountered some similar problems?
 
Could you breifly explain about "disconnected" operation ?

Regards,
Eun Kyoung

---

From: Eun Kyoung Paik <[email-masked]>
Date: Thu, 3 Jul 2003 14:59:18 +0900

Regards,
Eun Kyoung

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 Jul 2003 11:41:21 +0200

Eun Kyoung Paik wrote:
> Thank you for your kind reply. Please see inlines.
> 
>>> And I have another question on the implementation of nested 
>>> mobile networks. For example, let's think about following 
>>> topology.
>>> 
>>> In the figure, Parent MR may autoconfigure its CoA after it 
>>> listens RA of AR. Then, Child MR may autoconfigure its CoA after 
>>> it listens RA of Parent MR. After that, if Parent MR listens 
>>> Child MR's RA, Parent MR configures new CoA according to Child 
>>> MR's RA ?
>> 
>> One is that according to the stateless autoconfiguration mechanisms
>>  a router will not autoconfigure an address on an interface based 
>> on received RA's.  Parent MR is a router, so.
> 
> Then, how MR's egress interface configures its CoA when it moves into
>  a foreign link ? Doesn't it need RA from foreign link ?

Yes, exactly, it does need one.  That's why the egress interface of a MR
will act as if it were belonging to a host (not a router) when visiting
a foreign network.

>> The other is that Child MR is, in fact, visiting the network of 
>> Parent MR; when a MR is visiting, it acts as a host on its egress 
>> interface, not as a router.  Thus it will not send RA's on its 
>> egress interface if it is not at home, so Parent MR does not get 
>> RA's from Child MR.
> 
> 
> I wonder if parent MR's egress interrface listen the RA of child MR's
>  ingress interface.

A picture would help.  My picture is that Parent MR uses its egress to
connect to AR and ingress to connect to Child MR.  Child MR uses its
egress to connect to Parent and its ingress to connect to its mobile link.

In general, I think the MR's _ingress_ interface will listen for RA's
but will not use it to autoconfigure addresses.  The MR's _egress_
interface, when in a foreign link, will listen to RA's from AR and will
autoconfigure CoA.

Since the Child MR is acting like the parent MR, and child's egress
interface does not send RA (because it acts as a host on that interface)
then parent will not see any RA's coming from child MR.

> (Child MR's ingress interface may broadcast its RA for its VMNs.)

Yes, Child MR's ingress interface MUST broadcast RA (but not the
egress).  Right?

> And how can we distinguish egress interface from ingress interface 

That's a good question and in one implementation that is a "knob", that
is like a turning button, like a kernel variable that says which
interface is "egress".

> Could you breifly explain about "disconnected" operation ?

Ok, maybe "disconnected operation" is my name for it, but the issue was
mentioned under other names, where two nested mobile networks can't talk
to each other if their respective HA's are not available.  Many
discussions in the archives.  Many pros and cons of this being or not
being a problem.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 Jul 2003 11:41:21 +0200

Alex
GBU