Subject: [seamoby] I-D ACTION:draft-ietf-seamoby-mm-problem-00.txt

From: [email-masked]
Date: Tue, 20 Feb 2001 10:26:25 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Context and Micro-mobility Routing Working Group of the IETF.

	Title		: SeaMoby Micro Mobility Problem Statement
	Author(s)	: J. Loughney et al.
	Filename	: draft-ietf-seamoby-mm-problem-00.txt
	Pages		: 15
	Date		: 19-Feb-01
	
Seamless mobility requires preserving the capability, security, and
quality of service offered to a mobile node during handoffs. To
achieve seamlessness, low (ideally no) latency and low (ideally
zero) packet loss handoff protocols are needed. Limiting the effect
of handoffs has the potential to improve handoff performance in
terms of latency and packet loss. This draft identifies the problem
area for seamless mobility and defines the scope of the work for the
SeaMoby work group.

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

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-seamoby-mm-problem-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-seamoby-mm-problem-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: "Gary Kenward" <[email-masked]>
Date: Thu, 22 Feb 2001 23:05:49 -0500

> -----Original Message-----
> From: Hesham Soliman (ERA) [mailto:[email-masked]]
> Sent: Thursday, February 22, 2001 5:47 PM
> To: 'Michael Thomas'; Hesham Soliman (ERA)
> Cc: [email-masked]
> Subject: RE: [seamoby] I-D ACTION:draft-ietf-seamoby-mm-problem-00.txt
> 
> 
> > Hesham Soliman  (ERA) writes:
> >  > "The assumption is that a local protocol can address these goals
> >  >    better by limiting its applicability to a smaller 
> domain (such as an
> >  >    intranet - e.g. warehouse, and not the entire 
> internet as in the
> >  >    case of Mobile IP) and reverting to Mobile IP for the 
> general case
> >  >    of internet mobility support."
> >  > 
> >  > => This already assumes that the mm protocol is not 
> >  > based on MIP. I think it's premature to say so. Also I 
> >  > don't see why limiting the applicability of a protocol
> >  > to a local domain makes it "better". 
> >  > BTW what is "better" ?
> > 
> >    Um, that's exactly what HMIP does, yet I don't
> >    see you complaining about it.
> > 
> 	=> HMIP IS MIP with very minor extensions. 
> 	I had two simple questions, why is it assumed
> 	that MIP is only good for inter-domain mobility
> 	and what is"better". "better" needs to be explained.

*sigh* The problem is that "better" largely means faster
(and in some discussions, less complex). The problem being
that no one will agree on what "faster" means. There are no
solid numbers.

The IETF usually relies upon operational experience and empirical
measurements of operational networks to determine if a solution
is performing as it should. 

However, there is much at stake here. After 10+ years of development,
there is little, if any, operational experience with MIP (none with HMIP
or FH). And there are many who are do not believe that MIP will provide
the performance they need for wireless networks they wish to deploy
in the near future - they don't have time to wait for reports on operational
experience.

This discussion has been spinning around for at least 8 months now. 
No one is going to get any closer to defining "better". And the lack
of a crisp definition is not going to silence those that believe there 
is a better way. 

Just my 2 cents (Canadian) worth.

Gary

---

From: [email-masked]
Date: Fri, 23 Feb 2001 11:14:32 +0200

Hi Hesham,

> The problem needs to be explained in light of the existing
> solutions, otherwise it can't be a problem.

Just to be pendantic, do you mean to state that if there isn't
an existing solution for something, there cannot be a problem?
 
> Intro:
> 
>   "Current IP mobility solutions
>    tend to focus primarily on best effort data transport to and from a
>    mobile device where the routable IP address (for example, Mobile IP
>    Care-of Address) of the Mobile Device changes during handoff."
> 
> => I don't agree that the focus is only on best effort 
> services. As you know there is work to support real time
> services.

Noone stated that MIP is ONLY best effort, but there needs to be
more work done for realtime support.

>    better by limiting its applicability to a smaller domain 
> (such as an
>    intranet - e.g. warehouse, and not the entire internet as in the
>    case of Mobile IP) and reverting to Mobile IP for the general case

Better is subjective. From the abstract of
"draft-ietf-mobileip-hmipv6-01.txt"

   The proposed hierarchical mobility
   management for MIPv6 will reduce the amount of signalling to CNs and
   the HA and may also improve the performance of MIPv6 in terms of
   handoff speed. 

So, by limiting the scope of MM, we may improve the performance.  However,
after reading your comments & re-reading the introduction, I can see
how someone may see that we are implying the MIP won't cut the
mustard.  I don't think that this is the time to get into a 
MIP vs SeaMoby argument, so I will try to make the text more
balanced.

> "Within a limited number of hops"
> 
> => I don't get this, what does it mean ? domain ?

Someone has put forth a solution which involves limited
ad-hoc networking.  This is a solution, therefore we don't
want to promote it at the time being.  I do feel that we
need to allow the possibility of this solution (like the
solution of MIP) but debate it at the time of solutions.

> Ch 1.2
> 
> "Moreover, a lightweight approach, customized to the exact
>    requirements of local mobility while interoperable with a more
>    general mobility  mechanism (e.g. Mobile-IP)"
> 
> => Again assuming that the mm solution is not MIP-based

You're splitting hairs, but just to split the hair further,
the text now reads

	 general mobility  mechanism (e.g. vanilla Mobile-IP [2002])

My point being, if we want a MIP solution for SeaMoby, then we will
need to pull together a number of drafts/RFCs dealing with MIP
& MIP-extensions and describe how they should interoperate.
For example 'Route Optimazition with Fast Handover Hierarchial
Mobile IPv6 with AAA registration keys and Context transfer' ...

> "This procedure has strict timing
>                          requirement for the execution and low (zero)
>                          packet loss."
> 
> => Is it low or zero ?

The target is zero.  

> "Regional Registration for IPv4, IPv6"
> 
> => You mean HMIPv6 ?

Fixed that.
 
> Ch 3.1
> 
> "4)   Configurability:    Plug & Play of routers/base stations not
>                               addressed - need to configure 
> HA/FA/GFA's
>                               etc."
> => V6 ??

V6 doesn't address the capabilites of the routers & base stations. 
V6 does have autoconfiguration, but there's more to it.

> "Mobile Network      controversial.
>           Support:"
> 
> => Why is it controversial ?

Controversial because there are those that feel MIP does not
attequately support the needs of Mobile Networks.  This needs
to be analyzed.
 
> Ch 3.1.1
> 
> "3.1.1 Scalability Issues

This is Phil N's text, I'll let him debate it.

> In Ch 4.1.1
> 
> You mention this scenario and then you go into the details 
> of L2 interactions. I don't see this as being relevant for 
> IP protocols. You clearly defined an Access Point as an L2
> device and I agree with that, but this means that such device
> doesn't have IP in it. So I'm not sure why this section
> is needed and why refer to IEEE stuff.

If an access router is connected to 2 different access points,
which have overlapping coverage by 2 different L2s, there may
need to be some way to handle this.  MM may be needed to 
select between APs of different L2 types.  

br,
John

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 23 Feb 2001 12:23:52 +0100

Hello John,

> an existing solution for something, there cannot be a problem?
	=> Of course not, I meant the opposite. A problem can 
	only be a problem if there is NO existing solution. 
	That's why when you define a problem you should say that for 
	your particular requirements there is no solution.
> Better is subjective. 
	=> You just confirmed my point.

> From the abstract of
	Ok. 

> Mobile IPv6 with AAA registration keys and Context transfer' ...
	=> Ok.

> >                          requirement for the execution and low (zero)
	=> Please say that in the text.

> V6 doesn't address the capabilites of the routers & base stations. 
	=> You're talking about P&P and then referring to v4 entities
	as being a problem. I'm saying that you don't 
	have FAs on each link in v6. 

> V6 does have autoconfiguration, but there's more to it.
	=> John, is it not clear to you that the text only addresses
	v4 ? Are we meant to guess what configuration problems v6 have ?
> attequately support the needs of Mobile Networks.  This needs
	=> "feel" ? Ok I guess we can skip this one. 
> select between APs of different L2 types.  
	=> So the MN can select one of the 2 AP's right ?
	Is the suggestion that we need IP protocols for this choice 
	to be made ? 
	Perhaps that MM could be a function/API in the MN.
	It's just not obvious to me that we need L3 protocols 
	(between to nodes) for this, since the APs don't 
	have an L3 stack.

	Thanks,
	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 23 Feb 2001 12:08:59 +0100

> of a crisp definition is not going to silence those that believe there 
	=> So we should just do it anyway ! 
	I think you will find that (propoer) comparisons / simulations do exist. 
	I've seen comparisons done between the various mm protocols
	that addressed different aspects of performance and attempted 
	to define what "better" means. 
	When it comes to speed of handovers some people have 
	shown the opposite of what you said about MIP's speed.

	But we're again drifting here. My question was if you
	can't define why it's better and show some 
	proof (at least on paper!) then why have a draft ?
	Why not just decide that the group will do the mm
	work anyway. That would at least save time.

> Just my 2 cents (Canadian) worth. 
	My 2 cents (Australian) !

	Hesham

---

From: [email-masked]
Date: Fri, 23 Feb 2001 14:29:59 +0200

Hi Hesham,

Attached is a short volley on MIP support for Mobile Networks.

br,
John

Subject: Re: [seamoby-mm] Mobile Network support
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Date: Mon, 5 Feb 2001 17:04:43 +0200

At 10:07 PM 2/2/01 -0800, Charlie Perkins wrote:
>
>Hello again,
>
>I think there is something here that isn't technically correct.

I disagree.

Which Mobile IP rfc's explain how to support Mobile Networks using
IPv4 and optimal routing together ?

Which rfc's explain how to support Mobile Networks using IPv6 ?

If you find an answer to these questions, please also include the
section number for the text which describes it.

>
>Dana Blair wrote:
>
>> I would like to suggest the following text to be added to the list of 
>considerations
>> just above section 1.1
>>
>>     Need to support Mobile Networks as well as Mobile Hosts.
>>
>> Also, I would like to add the following text to section 3 when comparing
our
>> goals/requirements to other Protocols.
>>
>>     Mobile Networks should be a principle consideration of any mobility 
>protocol.
>>     rfc2002 addresses Mobile Networking but only in the context of using
a 
>tunnel to the
>>     Home Agent.  Neither draft-ietf-mobileip-optim-10.txt (IPv4 optimal 
>routing) nor
>>     draft-ietf-mobileip-ipv6-13.txt (Mobile IPv6) address Mobile
Networks.
>>
>
>It isn't correct to state that RFC 2002 or Mobile IPv6 fail to address
Mobile
>Networks.  On the contrary, mobile networks have been built using those
>protocol specifications.

I didn't say rfc2002 fails to address Mobile Networks.  I DID say that
rfc2002 fails to address mobile networks with optimal routing
(non-tunneled).  Nor does
the optimal routing draft address mobile Networks.

Mobile IPv6 does not even mention mobile networks.

It's possible that mobile networks have been built, but there is no
Mobile IP rfc explaining how to do this in an interoperable method.
Therefore any technique that may be working and not part of
a standard is proprietary.  The technique may be standardized
at some point in the future, but was not a consideration in documents
I mentioned.

>
>What may be considered missing is additional routing protocol that makes
>further specification towards eliminating routing inefficiencies for
aggregates
>of mobile nodes.  Nevertheless, the subject of mobile networks has been
>discussed multiple times, and certain changes and improvements made
>because of those discussions. Handling of multicast and broadcast have also
>been discussed numerous times.
>
>Perhaps a sharper definition of "support" would be helpful, in your first

What is confusing about the word support ?  Any standards activity regarding
mobility protocols should define how to enable mobile networks.

>suggested sentence to be added.  Do people believe that multicast is
>an important consideration for [seamoby-mm]?

If you wish to add
multicast to the problem statement draft, please submit some text that you
would like added.  We will discuss it at that time.

thanks,
Dana

>Regards,
>Charlie P.

Subject: Re: [seamoby-mm] Mobile Network support
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Sat, 3 Feb 2001 08:07:25 +0200

Hello again,

I think there is something here that isn't technically correct.

Dana Blair wrote:

> I would like to suggest the following text to be added to the list of
considerations
> just above section 1.1
>
>     Need to support Mobile Networks as well as Mobile Hosts.
>
> Also, I would like to add the following text to section 3 when comparing
our
> goals/requirements to other Protocols.
>
>     Mobile Networks should be a principle consideration of any mobility
protocol.
>     rfc2002 addresses Mobile Networking but only in the context of using a
tunnel to the
>     Home Agent.  Neither draft-ietf-mobileip-optim-10.txt (IPv4 optimal
routing) nor
>     draft-ietf-mobileip-ipv6-13.txt (Mobile IPv6) address Mobile Networks.
>

It isn't correct to state that RFC 2002 or Mobile IPv6 fail to address
Mobile
Networks.  On the contrary, mobile networks have been built using those
protocol specifications.

What may be considered missing is additional routing protocol that makes
further specification towards eliminating routing inefficiencies for
aggregates
of mobile nodes.  Nevertheless, the subject of mobile networks has been
discussed multiple times, and certain changes and improvements made
because of those discussions. Handling of multicast and broadcast have also
been discussed numerous times.

Perhaps a sharper definition of "support" would be helpful, in your first
suggested sentence to be added.  Do people believe that multicast is
an important consideration for [seamoby-mm]?

Regards,
Charlie P.

Subject: Mobile Network support
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Date: Sat, 3 Feb 2001 07:18:04 +0200

I would like to suggest the following text to be added to the list of
considerations
just above section 1.1

    Need to support Mobile Networks as well as Mobile Hosts.

Also, I would like to add the following text to section 3 when comparing our
goals/requirements to other Protocols.

    Mobile Networks should be a principle consideration of any mobility
protocol.
    rfc2002 addresses Mobile Networking but only in the context of using a
tunnel to the
    Home Agent.  Neither draft-ietf-mobileip-optim-10.txt (IPv4 optimal
routing) nor
    draft-ietf-mobileip-ipv6-13.txt (Mobile IPv6) address Mobile Networks.

thanks,
Dana

At 02:34 PM 1/30/01 +0200, [email-masked] wrote:
>Hi all,
>
>Please find the updated problem statement.  Mucho editorial work is needed,
>I know ...
>
>John
>
>

---

From: [email-masked]
Date: Fri, 23 Feb 2001 15:20:12 +0200

Hi Hesham,

> Did you read my answer to Mike ?
> if not, you can read HMIPv6 extended 
> mode to see how Mobile networks are supported in a 
> route optimised way. 

I did, but wasn't convinced.  I'll add HMIPv6
extended mode to my weekend reading :)

> As fo MIPv4 I agree that you can't do it in a route
> optimised way, but can you receive route optimised
> packets at all when following RFC2002 ?
> I don't think so.

Agreed.

John

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 23 Feb 2001 13:37:02 +0100

Hi John, 

Did you read my answer to Mike ?
if not, you can read HMIPv6 extended 
mode to see how Mobile networks are supported in a 
route optimised way. 
When Dana said it was not in the basic MIPv6 draft he 
was right, but it doesn't mean that it's not done.

Regards,
Hesham

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, 23 February 2001 11:30
> To:	[email-masked]; [email-masked]
>  << Message: Re: [seamoby-mm] Mobile Network support >>  << Message: Re: [seamoby-mm] Mobile Network support >>  << Message: Mobile Network support >>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 23 Feb 2001 15:05:28 +0100

Hi John,

> extended mode to my weekend reading :)
	=> No poblems. And if you're still not convinced
	please send your questions / comments to 
	the MIP list to help impove the solution.

	regards,
	Hesham

---

From: [email-masked]
Date: Fri, 23 Feb 2001 16:05:01 +0200

Hi James,

> Don't forget the cellular case where the network between the
> AP and the Access Router may not even have full mobile packets
> on it. It may have radio frames. I think this needs to be 
> supported as well.

Do you mean radio frames over IP?  That is a good point.

By the way, someone suggested to me that GTP in UMTS networks
is a micromobility protocol as well - not that I'm saying 
we want that to be our solution!

cheers,
John

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 23 Feb 2001 17:39:14 +0100

> James Kempf writes:
>  > on it. It may have radio frames. I think this needs to be supported 
>  > as well.
> 
>    Supported in what way? Certainly not by SEAMOBY, I hope.
>    If we have to "support" every bad network design, we
>    might as well give up now.
> 
	=> Why do I get the impression that you don't want to 
	have a technical discussion. What is "bad" design about
	the paragraph above ??? 
	Even if it is "bad", can you enlighten us and tell us why ?  

	Hesham

---

From: James Kempf <[email-masked]>
Date: Fri, 23 Feb 2001 10:05:08 -0800 (PST)

Hi Mike,

Ok, you have a point. Actually, what this is doing is implementing
a kind of L2 mobility over IP, which is orthogonal to actually
moving the IP point of connection. 

Whether that's "good" or "bad," I'll let you make the judgement. :-)

		jak

>X-Authentication-Warning: charizard.diameter.org: majordomo set sender to 
[email-masked] using -f
>From: Michael Thomas <[email-masked]>
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Date: Fri, 23 Feb 2001 09:51:22 -0800 (PST)
>To: James Kempf <[email-masked]>
>Cc: [email-masked], [email-masked]
>X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk 
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd 
bUcI'1!
>
>James Kempf writes:
> > In point of fact, macrodiversity resolution must be done at some point
> > back in the wired network. One can argue how useful or necessary including
> > macrodiversity is for a radio protocol, but CDMA currently
> > has it and there are good reasons (e.g. combatting Rayleigh fading) for
> > having it in. So having some kind of wired networks over which radio
> > frames are running to the macrodiversity resolution point
> > is a necessity for CDMA protocols.
> > 
> > Given that and the desire of many 3G operators and vendors
> > to use IP in their RANs, I don't see any reason why it should not
> > be considered.
>
>   Well, my question is what is "it"? Support is a pretty
>   loaded term, and I'm drawing a blank of what would be
>   new, IETFwise, about a set of l2-over-IP flows going
>   multiple places. Am I misremembering something? That
>   seems to be just a standard tunneling application which
>   doesn't doesn't have much of anything to do with CT or
>   MM.
>
>>  If one does consider it, it makes an even stronger case
> > for using a routing update based protocol instead of a tunnelling protocol,
> > because the time constraints on doing soft handoff are pretty strict, 
> > and the need to avoid mobile node involvement argues for maintaining the IP 
> > address. 
>
>   I wish I could be happy about that, but it still doesn't
>   make much sense to me. Let's make certain we're communicating:
>   The thingy responsible for macro-diversity (SDU, I think)
>   needs to transport multiple copies of the radio frames, not
>   the IP datagrams that arrived at the GGSN, to
>   the base stations that are visible to MN. These 
>   frames are encapsulated as IP datagrams whose
>   destination are the base stations involved with 
>   the mobile node at the time. The base stations
>   merely takes the radio frame and transmits it.
>   The mobile receives it, adds all of the frames
>   up as a L1/L2 operation up, and then
>   reassembles the IP datagram and delivers it.
>   Something similar happens in the reverse
>   direction.
>
>   Now, I certainly wouldn't disagree that there
>   are any number of challenges, not the least of
>   which is the implications for ISSLL, but I fail
>   to see what that has to do with whether MIP
>   or route based mobility is appropriate. MIP
>   never even comes into the picture at this level
>   because the _base stations and SDU's_ which
>   are the destinations of the radio frames aren't
>   mobile themselves. The tunneled data is just
>   plain old IP datagrams.
>
> > This kind of mobility is currently handled by dedicated radio
> > network layer protocols, but, given the right kind of micromobilty
> > protocol, I think it could be handled by IP transport mechanisms in the
> > future.
>
>   Sure, I'm all for IPifying everything, but
>   I really don't see what this has to do with
>   IP mobility qua IP mobility.
>
>	Mike

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 27 Feb 2001 14:45:11 +0100

> >Yes, but SeaMoby may need to address MIPv4 as well.  But, I will adjust
> >the language and mention MAPs (HMIPv6) as well.
> 
> SEAMOBY needs to consider both IPv4 and IPv6 solutions.
> 
	=> Exactly ! BTW, John, there is no need to have MAPs 
	in ARs. HMIPv6 does not require that at all. in fact we discourage it.

> >I will fix this & mention that plug & play isn't only about
> >autoconfiguration.
> >
> >I'll root around for some supporting info on this.  I can't remember
> >who wanted this point ...
> 
> That was me.  I'll state it a little more clearly.  Charlie and I debated this
> point on the list, so the debate may come back up here.
> 
> Mobile IPv4 (rfc2002 or route optimization draft) does not address how to support route opimization for
> Host on a Mobile Network.
> 
	=> RFC2002 and most MIPv4 implementations I know of 
	don't have route opt in general not just for Mobile 
	Networks. 

> Mobile IPv6 draft does not even mention Mobile Networks much less how to support
> route optimization for Hosts on a Mobile Network.
> 
	=> If the requirements is to only read MIPv6 and refuse to consider other
	proposals then I agree. 

> Let's not get too hung up on the scenarios.  The requirements process would
> weed good and bad ideas of the scenarios.
> 
> I don't think we should assume that the AP and AR can be combined
> into a single system. 
> 
	=> Sure.

>  Route advertisements is an example of
> an AP/AR advertising its network capabilities so there is already
> a precedent for layer 3 protocol. 
> 
	=> That's not true really, router advertisements are an example
	of an AR (_not_AP) advertising its capabilities

>  The MN may get information
> from Layer 3 and Layer 2 to make the "best" handover decision.
> 
	=> Of course, but our scope in IETF does not include 
	designing L2 protocols. That's why I don't know what is 
	the use of this scenario. I can understand a need for an 
	API in the MN, but not the need for L3 protocols to solve
	that scenario.

	Regards,
	Hesham

---

From: "Dana L. Blair" <[email-masked]>
Date: Tue, 27 Feb 2001 08:31:39 -0500

>mode to see how Mobile networks are supported in a 

I don't consider any heirarchical scheme to be consistent
with route optimization.  Route optimization means the
IP routing layer (IS-IS, BGP, OSPF, ...) of the internet chooses the best path
between client and server or one peer and another.  An
anchor point anywhere in the network is neither client nor
server nor peer and therefore (a) interferes with routing optimization introducing
unnecessary latency, and (b) reduces reliability by introducing a stateful
single point of failure.

>packets at all when following RFC2002 ?

There is a route optimizaton draft for Mobile IPv4.

thanks,
Dana

>>  << Message: Re: [seamoby-mm] Mobile Network support >>  << Message: Re: 
>[seamoby-mm] Mobile Network support >>  << Message: Mobile Network support >>

---

From: "Dana L. Blair" <[email-masked]>
Date: Tue, 27 Feb 2001 09:31:51 -0500

>	=> If the requirements is to only read MIPv6 and refuse to consider other

I don't think ignoring proposals is a requirement.  However there is no way to
predict which proposals will be adopted by the Mobile IP WG.  So we focussed
on the main documents rfc2002 and Mobile IPv6 draft.

I just did a quick study of other drafts that are working group items.  None
of the following include the phrase "mobile network" or "mobile router" which
is included in rfc2002:
Fasthandover for Mobile IPv6,
Low Latency handoffs for Mobile IPv4,
Mobility Support in IPv6,
Route Optimization in Mobile IP

I noticed that Hierarchical MIPv6 mobility management does include the
term mobile router.   I am glad to see that it is included, however I don't
agree with the Heirarchy in principle so this draft does not apply.

Seems to me that the dominate drafts ignore the first line of the charter statement
of Mobile IP while individuals so that it is being addressed.  Furthermore, all the
drafts assume that the cNode addresses a stateful single point of failure (Home Agent) that
inhibits route optimization instead of the IP endpoing (MN) so they are not
interesting to the micromobility problem we are trying to solve in SEAMOBY.

By route optimization I don't mean mobile IP route optimization.  I mean the more
basic principle of allow routers to choose the best path and route around failures thus
improving the reliability of communications between client and server or peers.

>	API in the MN, but not the need for L3 protocols to solve

Aggreed that designing Layer 2 protocols is out of scope.  By definig
layer 3 dependencies and impact of layer 2 is within scope.  The pilc
working group is evidence of that.

If a layer 3 handoff mechanism is proposed then we need to define the
information the facilitates the "best" handoff decision. 

thanks,
Dana

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 27 Feb 2001 18:14:47 +0100

> => That's you opinion and that's fine, but you can't say that 
> mobile networks are not supported just because you 
> don't like HMIP.
> 
> >> 
> >	=> Sure.
> >
	=> Hence my statement above about an API.

> information the facilitates the "best" handoff decision. 
	=> Agreed but I think you could do it with an API and 
	not necessarily an L3 protocol. Or at least the need 
	for an L3 protocol was not mentioned in the draft.

	Regards,
	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 27 Feb 2001 18:25:18 +0100

> >	means choosing the shortest path between two nodes
> >	on the Internet. 
> 
> Can you define node ?
> 
	=> Host ? Terminal ? 

> >	I hope you don't mean that having a router in the 
> >	middle that encapsulates a packet and forwards it
> >	to the right address is breaking the Internet 
> >	model. That _is_routing.
> 
> But that is not what a Home Agent does.  No user application like
> email or web browsing on the internet addresses a router.  The cNode
> and MN in Mobile IP actually address the Home Agent which has no
> user application executing on it.
> 
	=> No it doesn't address the HA, this not true at all. The application
	addresses the Home address of the MN. The HA receives the 
	packet because of its ND/ARP advertisements. I'm sure you 
	know that already. So I don't know why you say that.

> tunnels the packet.  The inner portion of an IP tunnel is the application
> layer of the outer header.  So the Home Agent is in effect an application
> layer switch in the middle of the network which is not too different than a NAT.
> 
	=> That is a gross misinterpretation of a HA. How could it possibly be a NAT ?
	Do I need to list all the protocols that do not work through a NAT ?
	A HA does not operate above L3. This is the whole point behind MIP.

> >> An
> >> server nor peer and therefore 
> >> 
> >	=> It's a router ! They are usually in the middle
> >	and they're not clients or servers.
> 
> See my point above.  The Home Agent is not a router.  
> 
	=> Of course it's a router, define a router ? 
	your claims above abou it being a NAT are wrong.
	The first few pages in the MIP spec tell you 
	that it's a router don't they ?

> Non-mobile
> clients, servers, and peers do not address routers.  IOW, the IP
> destination address of a packet originiating from a fixed client, server, or
> peer on the internet is not the address of a router.  
> 
	=> I think you need to reread MIP. The CN does not 
	address the HA.

> >	=> I agree, but there are ways of making it redundant
> >	like any other router.
> 
> The only way is stateful transfer which requires some state other
> than IP routing to be transfered.  It's expensive an wasteful.
> What about networks that want to be multihomed ?
> 
	=> I was talking about a transfer of the binding cache.
	Multihoming is not an issues here is it ?

	Regards,
	Hesham

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 28 Feb 2001 14:15:35 -0600

I don't mean to jump but IMHO here are some things to realize about MIP in
relation to these NAT statements:

Route Optimized MIP is essentially per-host routing with some signaling (BU)
and a double NAT function built into the end-nodes (hosts if you prefer).

Functionally you could decompose a MIP MN or a CN into the NAT, per-host
routing (binding cache) functions and the "pure" host (applications) which
uses the home addresses.

You could also think of the HA as a part of this double NAT as well; albeit,
it is using a tunnel to statelessly signal the address translation.

The reason I am trying to bring this up to people is to make them realize
the following:

- It is per-host routing.
- It is double NAT (address translation at both ends)

Because it is per-host routing the route tables of the hosts may indeed grow
large. For example, one of the hosts may be a website which millions of
mobile hosts communicate simultaneously. Imagine a media or even just an
HTTP server with a million per-host route entries. 

Are there server companies and chip manufacturers working on hardware
assisted look-up engines and code to do these lookups to meet the delay
requirements?

Another approach we might take it to move the double NAT and fast (per-host
routing) lookup functions to the (purpose built) subnet routers where they
might have a chance of scaling. 

This might also serve to provide simultaneous route optimization with
location privacy and allow the existing SA's between routers to be leveraged
in order to avoid the necessity of setting up SA's every time a mobile node
wishes to communicate with another node on the network.

I am also fairly convinced that there are solutions which do not compromise
the connectionless (redundant) nature of IP, especially in the IPv6 case.

Indeed this would not be creating a new protocol to solve the node mobility
problem - it would be changing IP, itself, to solve the node mobility
problem - essentially making a new "pure" IP.

O.K. fire away  - at least we might get off the "what is a router" debate.

Glenn

> From:	Hesham Soliman (ERA) [SMTP:[email-masked]]
> Sent:	Tuesday, February 27, 2001 11:25 AM
> To:	[email-masked]
> Subject:	RE: [seamoby] I-D
> ACTION:draft-ietf-seamoby-mm-problem-00.txt
> 
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 28 Feb 2001 23:03:36 +0100

Hello Glenn, 

A router is a device that forwards packets from one interface to
another. That makes a NAT a router and so is a HA. 
A router CAN definitely tunnel, I hope you agree with that.

A NAT is a device that hides addresses on one side of the 
network from the other side and the end nodes. Typically 
because they are not routable. 
A HA _does_not_hide addresses from anyone. The end nodes 
and the entire Internet can route a MN's Home address. 
NATs typically break end to end security and many peer to
peer protocols. A HA doesn't.

I'm a bit surprised by your analogy and definitions but 
I dont really think we should spend our lives looking 
for a definition that makes a HA look like a NAT. 
Surely there are better reasons for justifying
the mm problem and better things to do.

Regards,
Hesham

> From:	Glenn Morrow [SMTP:[email-masked]]
> Sent:	Thursday, 1 March 2001 7:16
> To:	'Hesham Soliman (ERA)'; 'Michael Thomas'
> Cc:	[email-masked]
> I don't mean to jump but IMHO here are some things to realize about MIP in relation to these NAT statements: 
> 
> Route Optimized MIP is essentially per-host routing with some signaling (BU) and a double NAT function built into the end-nodes (hosts if you prefer).
> 
> Functionally you could decompose a MIP MN or a CN into the NAT, per-host routing (binding cache) functions and the "pure" host (applications) which uses the home addresses.
> 
> You could also think of the HA as a part of this double NAT as well; albeit, it is using a tunnel to statelessly signal the address translation.
> 
> The reason I am trying to bring this up to people is to make them realize the following: 
> 
> Because it is per-host routing the route tables of the hosts may indeed grow large. For example, one of the hosts may be a website which millions of mobile hosts communicate simultaneously. Imagine a media or even just an HTTP server with a million per-host route entries. 
> 
> Are there server companies and chip manufacturers working on hardware assisted look-up engines and code to do these lookups to meet the delay requirements?
> 
> Another approach we might take it to move the double NAT and fast (per-host routing) lookup functions to the (purpose built) subnet routers where they might have a chance of scaling. 
> 
> This might also serve to provide simultaneous route optimization with location privacy and allow the existing SA's between routers to be leveraged in order to avoid the necessity of setting up SA's every time a mobile node wishes to communicate with another node on the network.
> 
> I am also fairly convinced that there are solutions which do not compromise the connectionless (redundant) nature of IP, especially in the IPv6 case.
> 
> Indeed this would not be creating a new protocol to solve the node mobility problem - it would be changing IP, itself, to solve the node mobility problem - essentially making a new "pure" IP.
> 
> > >     model. That _is_routing.>  
> >