headers
Internet-Drafts | 6 Jul 2005 00:50
Picon
Favicon

I-D ACTION:draft-ietf-nemo-ro-problem-statement-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Network Mobility Route Optimization Problem Statement
	Author(s)	: C. Ng, et al.
	Filename	: draft-ietf-nemo-ro-problem-statement-00.txt
	Pages		: 24
	Date		: 2005-7-5
	
   With current Network Mobility (NEMO) Basic Support, all
   communications to and from Mobile Network Nodes must go through the
   bi-directional tunnel established between the Mobile Router and Home
   Agent when the mobile network is away.  This results in various
   inefficiencies associated with packet delivery.  This document
   investigates such inefficiencies, and provides for the motivation
   behind Route Optimization (RO) for NEMO.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org 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-ietf-nemo-ro-problem-statement-00.txt".

A list of Internet-Drafts directories can be found in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien Bournelle | 6 Jul 2005 14:33
Picon

About section 2.5 in ro-problem-statement

Hi all,

 I take a look at draft-ietf-nemo-ro-problem-statement-00.txt.

 I basically have 2 questions concerning section 2.5:

 In the first paragraph, it is written that:

 "When Mobile Routers have no prior knowledge of their peers..."

 In this sentence, "peers" means other MRs, MNNs, both ?

 Then it is written that: "In particular, it is possible to adopt a tit
 for tat (T4T) strategy and forward traffic unless the other party
 proves to be uncooperative when it is sollicited." 

 I don't clearly understand this sentence. If we consider the Figure 1.
 MR3 uses MR2. So MR2 forwards traffic for MR3. But I don't see how MR3
 can be uncooperative from MR2 perspective. Could you clarify this ?

 regards,

--

-- 
julien.bournelle at int-evry.fr
Permalink | Reply | 3 comments |
headers
Chan-Wah Ng | 6 Jul 2005 16:12

Re: About section 2.5 in ro-problem-statement

Hello Julien,

First of all, thanks for reading the draft, and bringing comments.
See my response in line (I would expect Pascal to give you better
answers, but let me attempt any way).

On Wed, 2005-07-06 at 14:33 +0200, Julien Bournelle wrote:
> Hi all,
> 
>  I take a look at draft-ietf-nemo-ro-problem-statement-00.txt.
> 
>  I basically have 2 questions concerning section 2.5:
> 
>  In the first paragraph, it is written that:
> 
>  "When Mobile Routers have no prior knowledge of their peers..."
> 
>  In this sentence, "peers" means other MRs, MNNs, both ?

Used in this context, "peers" should refer to other Mobile Routers who
are trying to do the same thing (i.e. trying to "cooperate to improve
the network availability for all parties").

>  Then it is written that: "In particular, it is possible to adopt a tit
>  for tat (T4T) strategy and forward traffic unless the other party
>  proves to be uncooperative when it is sollicited." 
> 
>  I don't clearly understand this sentence. If we consider the Figure 1.
>  MR3 uses MR2. So MR2 forwards traffic for MR3. But I don't see how MR3
>  can be uncooperative from MR2 perspective. Could you clarify this ?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Julien Bournelle | 6 Jul 2005 16:28
Picon

Re: About section 2.5 in ro-problem-statement

Hi,

 thanks for your quick answer,

 comments inline,

On Wed, Jul 06, 2005 at 10:12:47PM +0800, Chan-Wah Ng wrote:
> Hello Julien,
> 
> First of all, thanks for reading the draft, and bringing comments.
> See my response in line (I would expect Pascal to give you better
> answers, but let me attempt any way).
> 
> On Wed, 2005-07-06 at 14:33 +0200, Julien Bournelle wrote:
> > Hi all,
> > 
> >  I take a look at draft-ietf-nemo-ro-problem-statement-00.txt.
> > 
> >  I basically have 2 questions concerning section 2.5:
> > 
> >  In the first paragraph, it is written that:
> > 
> >  "When Mobile Routers have no prior knowledge of their peers..."
> > 
> >  In this sentence, "peers" means other MRs, MNNs, both ?
> 
> Used in this context, "peers" should refer to other Mobile Routers who
> are trying to do the same thing (i.e. trying to "cooperate to improve
> the network availability for all parties").
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pascal Thubert (pthubert | 6 Jul 2005 16:59
Picon
Favicon

RE: About section 2.5 in ro-problem-statement

>>
>> What this sentence tries to illustrate is that mobile routers may
wish
>> to relay each others packets to the Internet.  Remembering they are
>> mobile, there may be times when MR3 is attached to MR2, and times
when
>> MR2 is attached to MR3.  So when MR3 is attached to MR2, should MR2
>> prove to refuse to provide connectivity to MR3, when the times comes
to
>> MR2 attaching to MR3, MR3 may refuse to help.
>
> how MR2 knows that it is forwarding traffic for MR3 and not from a
> MNNs ? I mean that your text implies that the MR2 is able to detect
> that MR3 is a Mobile Router and not a MNN.
>
> (maybe by inspecting BUs sent from ingress network ?)
>
[<PT>] This might depend on the RO solution :) Also, there might be some
minimal handshake between routers when the form a mesh. All to be
defined.

Pascal
Permalink | Reply | 502 comments |
headers
Thierry Ernst | 7 Jul 2005 03:42
Picon

Re: About section 2.5 in ro-problem-statement


> >> What this sentence tries to illustrate is that mobile routers may
> wish
> >> to relay each others packets to the Internet.  Remembering they are
> >> mobile, there may be times when MR3 is attached to MR2, and times
> when
> >> MR2 is attached to MR3.  So when MR3 is attached to MR2, should MR2
> >> prove to refuse to provide connectivity to MR3, when the times
> >comes
> to
> >> MR2 attaching to MR3, MR3 may refuse to help.
> >
> > how MR2 knows that it is forwarding traffic for MR3 and not from a
> > MNNs ? I mean that your text implies that the MR2 is able to detect
> > that MR3 is a Mobile Router and not a MNN.
> >
> > (maybe by inspecting BUs sent from ingress network ?)
> >
> [<PT>] This might depend on the RO solution :) Also, there might be
> some minimal handshake between routers when the form a mesh. All to be
> defined.

A scenario where MR2 is providing access to MR3 and later MR3 providing
access to MR2 seems to suggest an ad-hoc netsted NEMO. Is this
intentional ? Isn't this crossing a boundary between MANET and NEMO that
we should better avoid crossing ? 

In the general case, there would be a MR in a bus and then a passenger
with a MR. The MR in the bus would always provide connectivity to the MR
carried by the passenger, never the other way round.
(Continue reading)

Permalink | Reply | 502 comments |
headers
Chan-Wah Ng | 7 Jul 2005 04:17

Re: About section 2.5 in ro-problem-statement

On Wed, 2005-07-06 at 16:28 +0200, Julien Bournelle wrote:
> > 
> > >  Then it is written that: "In particular, it is possible to adopt a tit
> > >  for tat (T4T) strategy and forward traffic unless the other party
> > >  proves to be uncooperative when it is sollicited." 
> > > 
> > >  I don't clearly understand this sentence. If we consider the Figure 1.
> > >  MR3 uses MR2. So MR2 forwards traffic for MR3. But I don't see how MR3
> > >  can be uncooperative from MR2 perspective. Could you clarify this ?
> > > 
> > 
> > What this sentence tries to illustrate is that mobile routers may wish
> > to relay each others packets to the Internet.  Remembering they are
> > mobile, there may be times when MR3 is attached to MR2, and times when
> > MR2 is attached to MR3.  So when MR3 is attached to MR2, should MR2
> > prove to refuse to provide connectivity to MR3, when the times comes to
> > MR2 attaching to MR3, MR3 may refuse to help.
> 
>  how MR2 knows that it is forwarding traffic for MR3 and not from a
>  MNNs ? I mean that your text implies that the MR2 is able to detect
>  that MR3 is a Mobile Router and not a MNN. 
> 

Lots of ways.  Layer 2 identities, etc.

>  (maybe by inspecting BUs sent from ingress network ?)
> 

Perhaps.  The point is that there are scenarios where security policy is
forbidding traffic from visitors to be tunneled into the home network,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chan-Wah Ng | 7 Jul 2005 04:28

Re: About section 2.5 in ro-problem-statement

On Thu, 2005-07-07 at 10:42 +0900, Thierry Ernst wrote:
> > >> What this sentence tries to illustrate is that mobile routers may
> > wish
> > >> to relay each others packets to the Internet.  Remembering they are
> > >> mobile, there may be times when MR3 is attached to MR2, and times
> > when
> > >> MR2 is attached to MR3.  So when MR3 is attached to MR2, should MR2
> > >> prove to refuse to provide connectivity to MR3, when the times
> > >comes
> > to
> > >> MR2 attaching to MR3, MR3 may refuse to help.
> > >
> > > how MR2 knows that it is forwarding traffic for MR3 and not from a
> > > MNNs ? I mean that your text implies that the MR2 is able to detect
> > > that MR3 is a Mobile Router and not a MNN.
> > >
> > > (maybe by inspecting BUs sent from ingress network ?)
> > >
> > [<PT>] This might depend on the RO solution :) Also, there might be
> > some minimal handshake between routers when the form a mesh. All to be
> > defined.
> 
> A scenario where MR2 is providing access to MR3 and later MR3 providing
> access to MR2 seems to suggest an ad-hoc netsted NEMO. Is this
> intentional ? Isn't this crossing a boundary between MANET and NEMO that
> we should better avoid crossing ? 
> 

Not entirely.  Think of a PAN with a laptop and phone, and other geezmo
gadgets you have nowadays.  At times the laptop provides Internet
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thierry Ernst | 7 Jul 2005 05:41
Picon

Re: About section 2.5 in ro-problem-statement


> > 
> > A scenario where MR2 is providing access to MR3 and later MR3
> > providing access to MR2 seems to suggest an ad-hoc netsted NEMO. Is
> > this intentional ? Isn't this crossing a boundary between MANET and
> > NEMO that we should better avoid crossing ? 
> > 
> 
> Not entirely.  Think of a PAN with a laptop and phone, and other
> geezmo gadgets you have nowadays.  At times the laptop provides
> Internet connectivity through its built-in WLAN or even good old
> traditional Ethernet, at others, the phone provides Internet
> connectivity through its 3G access. 

I don't call this a nested NEMO, but a multihomed NEMO. I would rather
since this as a PAN with 2 MRs. 1 MR may be the default router at a
time, and the other one at another time. 

> > In the general case, there would be a MR in a bus and then a
> > passenger with a MR. The MR in the bus would always provide
> > connectivity to the MR carried by the passenger, never the other way
> > round. 
> > 
> Of-course, and the point of the sub-section is still there (although I
> can't fathom why a company that deploys a MR on a train would have
> security policy to forbid traffic from visiting nodes to be tunneled
> back to its home network).  
> 
> But, train is just one of the countless examples of NEMO, a fleet of
> ships on the sea is yet another.  Even in the train situation, suppose
(Continue reading)

Permalink | Reply | 2 comments |
headers
Margaret Wasserman | 7 Jul 2005 05:41
Favicon

NEW!! Internet Area Mailing List


[This message is bcc:ed to all INT area WGs, the IESG and the IAB.]

Hi All,

We have created an Internet Area mailing list -- int-area <at> ietf.org. 
This list will be used to announce Internet area BOFs, to discuss 
Internet area WG charter updates and to discuss other issues related 
to the Internet Area, as they arise -- such as whether we should hold 
an Internet area meeting in Paris.

If you wish to join the list, you can do so at:

https://www1.ietf.org/mailman/listinfo/int-area

The archives should be available at:

http://www.ietf.org/mail-archive/web/int-area/index.html

(Hopefully this will be the first message in the archive).

If you are interested in issues concerning the overall structure or 
scope of the Internet area and/or are interested in influencing how 
the Internet area is managed, I hope you will join this list.

Thanks,
Margaret
Permalink | Reply | 0 comments |

Gmane