Subject: [nemo] I-D ACTION:draft-ietf-nemo-ro-space-analysis-00.txt

From: [email-masked]
Date: Fri, 02 Sep 2005 18:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Mobility Working Group of the IETF.

	Title		: Network Mobility Route Optimization Solution Space Analysis
	Author(s)	: C. Ng, et al.
	Filename	: draft-ietf-nemo-ro-space-analysis-00.txt
	Pages		: 37
	Date		: 2005-9-2
	
   With current Network Mobility (NEMO) Basic Support, all
   communications to and from Mobile Network Nodes must go through the
   MRHA tunnel when the mobile network is away.  This results in
   increased length of packet route and increased packet delay in most
   cases.  To overcome these limitations, one might have to turn to
   Route Optimization (RO) for NEMO.  This memo documents various types
   of Route Optimization in NEMO, and explores the benefits and
   tradeoffs in different aspects of NEMO Route Optimization.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-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-ietf-nemo-ro-space-analysis-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-ietf-nemo-ro-space-analysis-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: Alexandru Petrescu <[email-masked]>
Date: Tue, 06 Sep 2005 14:55:33 +0200

Hello to authors of draft-ietf-nemo-ro-space-analysis-00.txt and thanks
for posting this draft.  It captures in a single document much of the ro
solution space and possibilities.

I have read it partially and I have a few comments.

I would suggest using the terms "prefix ownership" instead of the mix
"identity" of "location" for Mobile Routers.  While it is easy to
understand that the "identity" of a MH is its Home Address it is
difficult to agree that the MNP is the "identity" of a MR.  It is easier
to understand that MR "owns" a certain prefix and the "identity" of that
MR is its Home Address.

I would suggest not using the terms "implicitly" and "explicitly" for
the two ways of representing an MNN's identity, because of the confusion
that may arise with the terms "implicit" and "explicit" of the NEMO
modes of operation.  The NEMO Basic Support MR uses "implicit" mode of
signalling to HA its CoA by _not_ including MNP in the BU and "explicit"
mode by including MNP in the BU.  The document on ro space analysis uses
 "implicitly"  to represent MNP's identity by the use of MNP and
"explicitly" by the use of its address.

I would suggest to use "identity" to stand for MR's Home Address
exclusively.

> Binding Update with Mobile Network Prefix
> 
> This can be viewed as a logical extension to NEMO Basic Support, 
> where the Mobile Router would send binding updates containing one or 
> more Mobile Network Prefix options to the Correspondent Agent. The 
> Correspondent Agent having received the Binding Update, can then set
>  up a bi-directional tunnel with the Mobile Router at the current 
> care-of address of the Mobile Router, and inject a route to its 
> routing table so that packets destined for addresses in the mobile 
> network prefix will be routed through the bi-directional tunnel.

Actually I think the packets addressed to nodes in the moving network
will be routed with a routing header and not encapsulated through a
bi-directional tunnel.

> Although the Return Routability procedure allows the Correspondent 
> Agent to verify that the care-of and home addresses of the Mobile 
> Router are indeed collocated, it does not allow the Correspondent 
> Agent to verify the validity of the Mobile Network Prefix.

Right, and additionally it is difficult to design a method for testing
the return routability for each and every address falling with the MNP
limits.

Alex

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 07 Sep 2005 16:51:06 +0800

Hello Alex,

See responses in-line.

> I have read it partially and I have a few comments.

Thanks for reading it (albeit partially ;)).

> to understand that MR "owns" a certain prefix and the "identity" of that

Hmm .. wait a minute.  We are talking about identity of MNN, not MR.  In
NEMO, we always assume that it is the MNN behind the MR that is talking
to a CN.  So the binding at the CA should be a binding between identity
of MNN and some location.

Assuming the MNN is a LFN, its identity is derived from the MNP.  So,
the MNP is in fact an aggregation of all identities of MNNs on a Mobile
Network Link.

So, while I agree that the MNP is definitely not an identity of MR, I
maintain that the MNP is an identity for MNNs.

Having said that, things get a bit complicated if the MNN is in fact a
VMN.  In this case, its true identity is actually its own HoA, and has
nothing to do with the MNP.  However, I would argue in this case that
the term "Identity" is used very loosely in the sense of binding between
two addresses, one serving as identifier, the other as locator.

> "explicitly" by the use of its address.

Hmm.. okay, point taken.  But would it really be that confusing?  I am
willing to change it if I or someone can come up with other
expressions.   

> will be routed with a routing header and not encapsulated through a

Well, both ways could be done.  However, using a routing header would
mean that the recipient (i.e. MNN) need to be able to support this
routing header, which may not be that practical.  It also means that the
MNN is somewhat aware of the RO session.  Using a bi-directional tunnel
would keep the MNN completely out of the equation.

> the return routability for each and every address falling with the MNP

Correct.

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 07 Sep 2005 11:43:59 +0200

Chan-Wah Ng wrote:
>> Hello to authors of draft-ietf-nemo-ro-space-analysis-00.txt and 
>> thanks for posting this draft.  It captures in a single document 
>> much of the ro solution space and possibilities.
>> 
>> I would suggest using the terms "prefix ownership" instead of the 
>> mix "identity" of "location" for Mobile Routers.  While it is easy 
>> to understand that the "identity" of a MH is its Home Address it is
>> difficult to agree that the MNP is the "identity" of a MR.  It is
>> easier to understand that MR "owns" a certain prefix and the 
>> "identity" of that MR is its Home Address.
> 
> 
> Hmm .. wait a minute.  We are talking about identity of MNN, not MR. 
> In NEMO, we always assume that it is the MNN behind the MR that is 
> talking to a CN.  So the binding at the CA should be a binding 
> between identity of MNN and some location.

Even so it does not follow.  Clearly the MNP can not be the identity of
any unique node: not the identity of an MR, not the identity of an MNN,
not the identity of an LFN.

>  the MNP is in fact an aggregation of all identities of MNNs on a 
> Mobile Network Link.
> 

Even if MNP is the identity of all the MNNs that derive their addresses
from it it's difficult to understand.  Identity of a host should be a
unique value representative for that host.  MNP being an identity for
several hosts it means that those hosts have the same identity,
indistinguishable from one another.

If the MNP is the identity of all LFNs then do LFNs still use their
(Home) Address as an identifier?  Which is the right identifier for an
LFN - its MNP or its Address?

> Having said that, things get a bit complicated if the MNN is in fact 
> a VMN.  In this case, its true identity is actually its own HoA, and 
> has nothing to do with the MNP.

I agree.  So how about LFN, what best represents the identity of LFN -
its address or the MNP?

> However, I would argue in this case that the term "Identity" is used 
> very loosely in the sense of binding between two addresses, one 
> serving as identifier, the other as locator.

The discussion identifier vs locator raised much controversy in the
past.  I don't see why trying to extend the discussion identifier vs
locator from Mobile Hosts to Mobile Routers.  Just because for Mobile
Hosts the identifier is the Home Address could not mean that we must
find a similar identifier for Mobile Routers, right?

The RO problem and RO solution space can exist and have been described
in illustrative terms w/o using the identifier vs locator discussion.

>> I would suggest not using the terms "implicitly" and "explicitly" 
>> for the two ways of representing an MNN's identity, because of the 
>> confusion that may arise with the terms "implicit" and "explicit" 
>> of the NEMO modes of operation.  The NEMO Basic Support MR uses 
>> "implicit" mode of signalling to HA its CoA by _not_ including MNP 
>> in the BU and "explicit" mode by including MNP in the BU.  The 
>> document on ro space analysis uses "implicitly"  to represent MNP's
>>  identity by the use of MNP and "explicitly" by the use of its 
>> address.
> 
> 
> Hmm.. okay, point taken.  But would it really be that confusing?  I 
> am willing to change it if I or someone can come up with other 
> expressions.

In my oppinion, "explicit and implicit" ways of representing identities
is difficult to understand already because it relates to "identities".

> Normally, Route Optimization would mean that a binding between the 
> Mobile Network Node's identity and location is registered at the 
> Correspondent Agent.  Before exploring into different ways of binding
>  location to identity (see Section 5.5), one must first ask how the 
> identity of the Mobile Network Node is represented.

Even if there were any particular ways of representing an identity NEMO
shouldn't care about it.  Maybe HIP, CGA and other WGs - yes.  I could
well imagine the multihoming space with SHIM or Monami6 also take
identity as a central goal.  But RO solution space no.

> 5.5  How is Identity Bound to Location? ... to the location of the
> parent Mobile Router; ... to a sequence of locations ... ... to the
> location of the root ...

The question doesn't fit the answer.  The right question would have been
"To what location should the Identity be bound".

And, instead of using the terminology "identity vs location" one could
re-formulate as:

What is the contents of a binding cache entry?
1. MR's CoA, LFN's HoA.
2. MR1's CoA, MR2's CoA... MRn's CoA, LFN's HoA where MR1..MRn are
   nested.
3. TLMR's CoA, LFN's HoA.

>>> where the Mobile Router would send binding updates containing one
>>> or more Mobile Network Prefix options to the Correspondent Agent.
>>> The Correspondent Agent having received the Binding Update, can
>>> then set up a bi-directional tunnel with the Mobile Router at the
>>> current care-of address of the Mobile Router, and inject a route
>>> to its routing table so that packets destined for addresses in
>>> the mobile network prefix will be routed through the 
>>> bi-directional tunnel.
>> 
>> Actually I think the packets addressed to nodes in the moving 
>> network will be routed with a routing header and not encapsulated 
>> through a bi-directional tunnel.
> 
> 
> routing header, which may not be that practical.  It also means that 
> the MNN is somewhat aware of the RO session.  Using a bi-directional 
> tunnel would keep the MNN completely out of the equation.

Yes, sorry, I always seem to forget this aspect.

Alex

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 07 Sep 2005 20:11:43 +0800

Hello Alex,

Ok, so you are not happy with the terms identity (vs locator).  I am now
challenging you to come up with more adequate terms.

Yes, I know you suggested going into specific (MR's CoA, LFN's HoA).
However, that's what we want to avoid.  The good thing about going into
specific is that it is not ambiguous.  However, it is only suitable for
a specification.  This draft, however, is trying to generalize the RO
solution space.  If I use terms "LFN's HoA is bount to MR's CoA", I
foresee even more objections:

(1) XXX: "Hey, but my proposal is not LFN's HoA is bound to MR's CoA,
its bound to MR's HoA" 

(2) YYY: "Hey, but LFN has no HoA nor CoA.  Its simply an *address*."

(3) ZZZ: "Hey, you fail to consider VMN's CoA ..."

no, its a rat hole I am trying to avoid.  

I need terms X and Y that are general enough to represent "X is bound to
Y", where X can be anything from LFN's address, VMN's CoA, MNN's HoA,
MNP, and Y can be anything from MR's HoA, MR's CoA, TLMR's CoA, a series
of MRs' CoA, etc ...

The best terms I have come up with is location and identity.  If you
have better suggestions, let me know and I'll appreciate that.  Else, I
think this debate is going nowhere.

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 07 Sep 2005 14:37:37 +0200

Hello Chan-Wah, thanks for replying.

Chan-Wah Ng wrote:
> Hello Alex,
> 
> Ok, so you are not happy with the terms identity (vs locator).  I am
> now challenging you to come up with more adequate terms.
> 
> However, that's what we want to avoid.  The good thing about going
> into specific is that it is not ambiguous.  However, it is only
> suitable for a specification.  This draft, however, is trying to
> generalize the RO solution space.

Generalize the solution space... hmmm.

> If I use terms "LFN's HoA is bount to MR's CoA", I foresee even more
> objections:
> 

Ok, one could say it that way.  And I perfectly understand that phrase.
 I like it much better than saying "MNN identity not bound to MR
identity, but bound to MR location".

> (2) YYY: "Hey, but LFN has no HoA nor CoA.  Its simply an *address*."

Ok, and I perfectly agree with using "LFN's address" instead of "LFN's
identity".

> (3) ZZZ: "Hey, you fail to consider VMN's CoA ..."

Using "identifier" and "locator" terms are as useless as using the "VMN"
term.  "VMN" is in no way different than "MN" in terms of what protocols
they implement and code they execute.

Other potential discussions that rely on "id vs locator" is "VMN's
location belongs to the MR's identity but VMN's identity is not MR's
identity".

> no, its a rat hole I am trying to avoid.

Yes, me too, that is why I suggest not using the locator vs identifier
discussion in the ro solution space draft.

> I need terms X and Y that are general enough to represent "X is bound
> to Y", where X can be anything from LFN's address, VMN's CoA, MNN's
> HoA, MNP, and Y can be anything from MR's HoA, MR's CoA, TLMR's CoA,
> a series of MRs' CoA, etc ...
> 
> have better suggestions, let me know and I'll appreciate that.  Else,
> I think this debate is going nowhere.

Sorry, I don't mean to get the debate nowhere.

Implementation-wise here's terminology:

"VMN" term makes no sense: it's either an MH or an MR.  "VMN" implements
nothing else than Mobile IPv6.

"MNN" term makes no sense: it's either an MH or an MR or an LFN.

"TLMR" makes no sense: it's an MR.

VMN, MNN and TLMR was used in informal discussions to mean the
following: VMN is an MH that visits an MR's moving network and that has
a different HA than that MR.  MNN has same HA.  TLMR is an MR that is
attaching to a fixed infrastructure and below which several MR's are
attaching in a nested manner, none being attached to the fixed
infrastructure.

That gives:

"LFN's address is bound to MR's Home Address"
"LFN's address is bound to MR's Care-of Address"
"LFN's address is bound to the MR's Care-of Address that is attached to
 the fixed infrastructure".
"LFN's address is bound to a series of MRs' Care-of Addresses within
 which that LFN is nested"
"MH's Care-of Address is bound to ..."
"MH's Home Address is bound to ..."
"MR's Care-of Address is bound to ..."
"MR's Home Address is bound to ..."

Which in the end leads to:

"In the RO solution space, address bindings maintained at the CN may be
 structured differently.  Addresses or prefixes of a host or of a router
 may be bound to each other or to addresses or prefixes of another host
 or router.   For example, in a moving network composed of an LFN and an
 MR, the LFN's address may be bound to MR's CoA.  Alternatively, the
 LFN's address may be bound to the MNP owned by that MR.  In another
 example where two nested moving networks are employed, the LFN's
 address may be bound to both MR's Care-of Addresses.  Each different
 structure for the binding represents a different RO solution".

In my oppinion this stays generic enough and still suggests real behaviour.

Just two cents worth.  Thanks again for putting up the draft.

Alex

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 08 Sep 2005 10:58:35 +0800

Hello Alex,

er ... thanks for replying to my replies?  :)

I kind of like the idea of simply using "address".  Anyway that's what
this is all about, "binding an address to another address".

However, I don't quite agree to your logic behind arriving at using LFN.
In fact I see it the other way round.  

All we want to do is to consider how an address of X is bound to an
address of Y.  X is any node behind a mobile router (which, by
definition, is MNN), and Y is a mobile router, or the TLMR (which is
also a mobile router).

So, instead we should have used things like

"MNN's address is bound to its MR's address"
"MNN's address is bound to a sequence of MRs' addresses"

All is fine, but with one catch: We try as much not to use abbreviations
in the draft, then the expression "MNN's address" would expand to be
pretty long.

/rgds
/cwng