Subject: RE: [seamoby] Is Mobile IP too slow or is Routing Table Update To o slow? (was....)

From: Gopal Dommety <[email-masked]>
Date: Mon, 26 Feb 2001 02:16:02 -0800

At 10:13 PM 22/02/01 -0500, Gary Kenward wrote:

>I asked the question early on as to how slow was MIP (on 
>the CT email list). The only concrete answer I received was 
>2-3 seconds for a handover. A single data point, to be sure, 
>but it doesn't sound too fast to me. 

Normal MIP can be made to handoff in 200-300ms ms (using L2 trigger to recognize movement- 
this is L2 trigger and solicitation). It is also possible to reduce it further. NOTE: There are
several variables eg, latency between the FA and HA, movement detection etc. The 200-300ms 
is from measurements in a setup with some reasonable delay between the FA and HA. 

-Gopal

>The email exchange is available on the CT archive. 
>
>Gary 
>
>> -----Original Message----- 
>> From: James Kempf [<mailto:[email-masked]>mailto:[email-masked]] 
>> Sent: Wednesday, February 21, 2001 5:30 PM 
>> To: [email-masked] 
>> Cc: [email-masked] 
>> Subject: [seamoby] Is Mobile IP too slow or is Routing Table 
>> Update Too 
>> slow? (was....) 
>> 
>> 
>> Phil, 
>> 
>> Just one comment... 
>> 
>> >While this seems to be a very concrete item for the working 
>> group it's 
>> >difficult to see the problem statement in the rest of the 
>> document for which 
>> >this work would apply.  It appears to be a solution without 
>> a problem. 
>> >Specifically one might want to state a problem and then why 
>> a combination of 
>> >mobile ip fast handovers and regional registrations wouldn't 
>> suffice to 
>> >solve it. 
>> > 
>> >pdn>Early on, I had a single sentence problem statement that 
>> b*tched about 
>> >pdn>how slow mobile IP would be if/when used in a tangle of 
>> pico cells 
>> >pdn>and how completely unnecessary it is in these scenarios. 
>>  It got yanked. 
>> >pdn>I still believe we need a single statement that does 
>> complain about 
>> >pdn>how MIP is intended for macro not micro-mobility. 
>> > 
>> 
>> I've heard this mentioned a number of times and I have not seen the 
>> numbers to prove it. I've also heard the opposite, namely that 
>> a routing update solution would be too slow because the convergence 
>> of routing tables is a slow process. 
>> 
>> The point is, nobody really knows. It seems to me that one of the 
>> charter items for Seamoby might be to find out if there is a problem. 
>> Some hard, cold data can do alot to convince. 
>> 
>>               jak 
>> 
>>

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 27 Feb 2001 06:22:03 -0500

Hi,
 
I am really confused with this discussion...Are you talking about rfc2002bis
alone or you put things like Fast Handoffs in the picture? Let me assume the
latter...
 
What is "fast" referring to? May I assume that we are talking about fast
from the point of view of the mobile? If yes, then Mobile IP with Fast
Handoff extensions as standardized in MIP WG is as fast is it is going to
get from the point of view of the mobile and you may notice that these
extensions do not depend on regional/hierarchical schemes. i.e.: so called
"real time" applications should work  just fine with Fast Handoffs....
 
What is the "scaling problem" exactly? The whole point of Fast handoff
mechanisms is to make sure that the time it takes to do MIP Registration to
your Home Agent or to whatever regional/hierarchical midpoint becomes
non-time-critical...i.e.: The only thing that regional/hierarchical schemes
give you is less signaling traffic over the network in the cases were your
Home Agent happens to be far away...So, is this the scaling issue with
Mobile IP that you are referring to?
 
Regards
George

-----Original Message----- 
From: Claude Castelluccia [mailto:[email-masked]]
Sent: Tuesday, February 27, 2001 8:51 AM
To: Andrew T. Campbell
Cc: 'Charlie Perkins'; 'Gary Kenward'; [email-masked]
Subject: Re: [seamoby] Is Mobile IP too slow or is Routing Table Update To o
slow? (was....)

Hello, 

"Andrew T. Campbell" wrote: 

Hello Charlie: 

I'm in agreement that MIP can run fast - but you wouldn't 
want to do that in a large scale way, right?

For the large scale scenario, you probably  have to use HMIP that is only a
simple extension to MIPv6. HMIPv6 use the same components, same registration
protocols, ... than 
MIPv6 and I see (or at least I'd like to see it)  it as part of MIPv6... 

I am convinced that with appropriate parameters (rt adverts. frequency. MAP
location,....) you can handle 
voice handover with Mobile IPv6 in a small network...but you probably need
the hierarchical extension for a large scale scenario.... 

regards, 
Claude. 

I think you are hinting at that in your response. 

BTW, do you have a reference for the Mobile IP handling 
voice? 

Thanks, 
--- 
Andrew 
http://comet.columbia.edu/~campbell <http://comet.columbia.edu/~campbell>  

> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]On 
> Behalf Of Charlie Perkins 
> Sent: Monday, February 26, 2001 5:44 PM 
> To: Gary Kenward 
> Cc: [email-masked] 
> Subject: Re: [seamoby] Is Mobile IP too slow or is Routing 
> Table Update 
> To o slow? (was....) 
> 
> 
> 
> Hello Gary, 
> 
> Mobile IP can be arbitrarily fast or slow.  If you'd like to make 
> it slow, crank down the advertisement rate to once per hour. 
> If you'd like it fast, register in response to layer-2 triggers over 
> a fast core network.  There isn't any one answer.  However, 
> it has been shown that, given appropriate and obvious parameters, 
> Mobile IP can handle voice handovers. 
> 
> Regards, 
> Charlie P. 
> 
> 
> Gary Kenward wrote: 
> 
> > 
> > 
> > > From: James Kempf [ mailto:[email-masked]
<mailto:[email-masked]> ] 

-- 

----------------------------------------

Claude CASTELLUCCIA, INRIA Rhone-Alpes  

ph:  +33 4.76.61.52.15 (fax: 52.52)

http://www.inrialpes.fr/planete/ <http://www.inrialpes.fr/planete/>

---

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

> >For the large scale scenario, you probably  have to use HMIP that is only a simple extension to MIPv6. HMIPv6 use the same components, same registration protocols, ... than 
> >I am convinced that with appropriate parameters (rt adverts. frequency. MAP location,....) you can handle 
> >voice handover with Mobile IPv6 in a small network...but you probably need the hierarchical extension for a large scale scenario.... 
> 
> There are several components to handoff delay (see an  old anchor handoff draft). One of the delays is the backhaul delay 
> (most of the time this is not the problem unless you are doing VPN etc). If this is a problem it is better to perform anchor kind of a handoff. 
> Hierarchical instantiations do help but mainly to reduce the signaling (or limit the signaling to the local domain).
> 
	=> I agree but it is also important to remember that reducing the amount of signalling 
	will actually speed up the handover. In MIPv6 BUs can also be sent to CNs which
	might also be MNs (connected to wireless links). Therefore the delays can be significant. 
	I think combining hierarchy with handoff anticipation (what was done in the Fast 
	Handoffs team) will improve the handover speed significantly.

	Hesham

---

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

>  
> ..i.e.: The only thing that regional/hierarchical schemes give you is less signaling traffic over the network in the cases were your Home Agent happens to be far away..
> 
	=> The amount of signalling is not dependant on how far away the HA is. 
	What HMIP gives you is reduced signalling, better routing and ability to 
	better handle frequent movements. The "better routing" part is due to 
	the fact that packets do not need to be routed via the old AR first. Of course
	the old AR may in many cases not be directly connected to the new AR
	(ie. not sharing a link with the new AR). 
	Hesham 

> 	Subject: Re: [seamoby] Is Mobile IP too slow or is Routing Table Update To o slow? (was....)
> 	
> 	
> 	  
> 	Hello, 
> 
> 		<http://comet.columbia.edu/~campbell> 
> 
> 		> From: [email-masked] [ <mailto:[email-masked]>]On 
> 		> > > From: James Kempf [ <mailto:[email-masked]>] 
> 		> > > >Specifically one might want to state a problem and then why > 
> 		> > > a combination of 
> 	<http://www.inrialpes.fr/planete/>
> 	  
>

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 27 Feb 2001 07:46:56 -0500

For whatever reason I do not get my e-mails back from the mailing list
:-( ...anyway... 

Hesham,

I agree with what you are saying...regional/hierarchical improves on packet
routing at the edge of the network...That is why I said in another e-mail
that micromobility protocols applied on tree networks take this optimization
to its limit.

I think we agree on this.

George

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Tuesday, February 27, 2001 12:28 PM
To: 'George Tsirtsis'; 'Claude Castelluccia'; Andrew T. Campbell
Cc: 'Charlie Perkins'; 'Gary Kenward'; [email-masked]
Subject: RE: [seamoby] Is Mobile IP too slow or is Routing Table Update
To o slow? (was....)

>  
> ..i.e.: The only thing that regional/hierarchical schemes give you is less
signaling traffic over the network in the cases were your Home Agent happens
to be far away..
	=> The amount of signalling is not dependant on how far away the HA
is. 
	What HMIP gives you is reduced signalling, better routing and
ability to 
	better handle frequent movements. The "better routing" part is due
to 
	the fact that packets do not need to be routed via the old AR first.
Of course
	the old AR may in many cases not be directly connected to the new AR
	(ie. not sharing a link with the new AR). 
	Hesham 

> 	For the large scale scenario, you probably  have to use HMIP that is
only a simple extension to MIPv6. HMIPv6 use the same components, same
registration protocols, ... than 
> 	I am convinced that with appropriate parameters (rt adverts.
frequency. MAP location,....) you can handle 
> 	voice handover with Mobile IPv6 in a small network...but you
probably need the hierarchical extension for a large scale scenario.... 

> 		> > > > 
> 		> > > 
> 		> > > I've heard this mentioned a number of times and I have

> 		> not seen the 
> 		> > > a routing update solution would be too slow because
the 
> 		> convergence 
> 		> > > charter items for Seamoby might be to find out if
there is a 
> 		> > problem.

---

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

> >> 
> >> There are several components to handoff delay (see an  old anchor handoff 
> >draft). One of the delays is the backhaul delay 
> >> (most of the time this is not the problem unless you are doing VPN etc). 
> >If this is a problem it is better to perform anchor kind of a handoff. 
> >> Hierarchical instantiations do help but mainly to reduce the signaling (or 
> >limit the signaling to the local domain).
> >> 
> Keeping the routing change closest to the edge maximal speeds up the handover.  So
> your suggesting is only valid if every router becomes and anchor point which would
> be redundant with routing protocols.
> 
	=> Not edge routers. Two or three hops on the wire
	is an insignificant delay compared to a RTT over the air.

	Hesham

---

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

At 01:20 PM 2/27/01 +0100, Hesham Soliman  (ERA) wrote:
>> >For the large scale scenario, you probably  have to use HMIP that is only 
>a simple extension to MIPv6. HMIPv6 use the same components, same 
>> >voice handover with Mobile IPv6 in a small network...but you probably 
>need the hierarchical extension for a large scale scenario.... 
>> 

thanks,
Dana

---

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

> I am sure voice handover using Mobile IP could be made to work over a few hops with a few
> nodes.  However, if we consider that a registration message may require several hops
> that span the globe over one or more bandwidth constrained networks, then the propogation delay
> could significantly contribute to handover
> 
	=> However if we consider other localised mobility management 
	techniques provided by MIP like regional reg for MIPv4 and HMIPv6 for 
	MIPv6, propagation delays will not be so significant.

> Some handover technique where the convergence point of the new access link compared
> to the old is closer to the MN is needed to facility seamless handover.  
> 
	=> Yes the techniques exist.

> Maintaing the same
> IP address between ALn and ALn+1 removes the need for Home Agent interaction.
> This is what we tried to say in the micromobility problem statement.
> 
	=> How can you maintain an address between two ARs ? 
	Of course within one subnet it is possible. Between ARs 
	I don't see how or why ?

	Anyway the HMIP approaches (for v4 and v6) provide 
	what you're asking for except the address changes 
	as far as the MN is concerned, bu not for the outside world.

	Regards,
	Hesham

---

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

>	MIPv6, propagation delays will not be so significant.

Not as significant but the tradeoff is unoptimal routing and a single point of
failure.  The best optimization would be to let the routing protocols converge.

>	Of course within one subnet it is possible. Between ARs 

Have your heard of a routing protocol ?

>	as far as the MN is concerned, bu not for the outside world.

Then HMIP does address the problem we have mentioned.  All of the
fixed endpoints on the interent work by keeping the same IP address.
A client addresses a server directly.  A server addresses a client directly.
They don't address something in the middle of the network.  Mobile Devices
should work the same way.  If the MN (client) address changes but the
Server does not see this, then the server must be addressing something (home Agent) in
the middle of the network.

That something is a single point of failure that prevents the network from choosing the
best routing between the client and server and thus will not scale in the way that the
internet has scaled.

thanks,
Dana

---

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

At 02:58 PM 2/27/01 +0100, Hesham Soliman  (ERA) wrote:
>> Not as significant but the tradeoff is unoptimal routing 
>> 
>	=> Can you please explain where the "unoptimal" routing 
>	comes from ? 

Anything that anchors a transport path in the middle of the IP network is
unoptimal routing.

>
>> The best optimization would be to let the routing protocols converge.
>> 
>	=> Yes, ideally we'd like to change the routing tables every
>	where, but that doesn't scale well when applied to the whole
>	Internet.

You are assuming a particular solution in your statement but have not
defined it.  You have revealed the need for a requirements process to substantially and
objectively analyze what the problems
are and what solutions may exist.  This is what we are trying to do in
SEAMOBY.

>	=> Have you heard of topologically correct addresses?
>	Have you heard of IPv6 ? In this funny technology the 
>	IPv6 node gets an address that belongs to the subnet
>	it's on. Otherwise its address becomes topologically 
>	incorrect. So when you hange routers, you change addresses.

Again you are assuming a solution.  At this point I am just trying to
ensure that we go through a requirements process instead of leaping
to any particular solution.  We should considering the historical internet addressing
model where clients, servers, and peers address each other and not
devices in the middle of the network.

thanks,
Dana

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 27 Feb 2001 11:28:27 -0500

The delay voice for conversational voice is 250 ms end-to-end, 
15ms variance. I don't have numbers for digital video (MPEG-4,
or even MPEG-2), but it would seem reasonable that the delay
numbers would be as stringent.

Gary

> From: Gopal Dommety [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 5:16 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf';
> [email-masked]
> Cc: [email-masked]
> >> From: James Kempf 
[<mailto:[email-masked]>mailto:[email-masked]]

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 27 Feb 2001 11:33:38 -0500

Thanks Charlie.

I would also like to read the reports that show that MIP
can handle voice, if they are available to the public.

Cheers,
Gary

> From: Charlie Perkins [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 8:44 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> > > From: James Kempf [mailto:[email-masked]]

---

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

>  > > Not really.  I see the HMIP solution as equivalent to introducing NAT's into
>  > > the network.  It breaks end to end addressability.
>  > > 
>  > 	=> I really don't see how it could possibly be a NAT
>  > 	but I already explaioned that in a previous mail.
> 
>    I don't think I agree with Dana's analogy with
>    NAT's, but there is something at stake here. 
> 
>    Right now with the fixed Internet, my host need
>    only know of exactly one router -- the default
>    router. Many argued that even that was too
>    onerous of a piece of knowledge, and things
>    like DHCP (nee bootp) were invented which
>    addressed that.
> 
>    Addition of a HA adds yet another layer of
>    must-know requirements, 
> 
	=> True. 

> and HMIP, FMIP, and
>    all the rest that a MN must keep track of keeps
>    adding to the complexity of the client at the
>    cost of understanding the network topology. 
> 
	=> I don't thinkyou need to know the network
	topology based on these proposals. In what 
	people refer to as FMIP, you only need to know
	your default router. Clearly the MN already knows 
	that.
	In HMIP, you need to know the MAP from the
	information received in the router advertisement.

>    This is especially true with HMIP which 
>    requires lots of knowledge of the network.
> 
	=> Why is that ? Please explain this so we
	could make it clearer in the draft, because 
	I don't believe you need to know much 
	about the network, except of course for the 
	information in the MAP option.

>    All in all, this seems to be headed us back
>    to the bad old days of UUCP bang-paths. There
>    is considerable reason, IMO, to be extremely
>    skeptical of things which happily -- as if it
>    something new or important -- bring us full circle
>    to that which we managed to escape from because
>    of IP.   
> 
	=> Nothing wrong with being skeptic, all I asked 
	was some justification for the skepticism. 
	I agree with the points made about single points 
	of failure and I don't think anyone would disagree
	with you on that. But doing another micromobility
	protocol that will still need the macro mobility
	one (MIP) won't solve this problem.

	Hesham

---

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

> Hesham Soliman  (ERA) writes:
>  > 	=> So you're only objection is clearly the redunduncy issue. 
>  > 	We've already planned to prposing a solution for that anyway. 
> 
>    And least cost routing. And administrative
>    overhead. And general complexity of having an
>    overlay network.
> 
	=> What administratve cost ? Can you explain 
	the complexity of the so called overlay network?
>  
>  > > By route optimization I don't mean Mobile IP routing
>  > > optimization.  
>  > > 
>  > > I mean the more basic principle of letting routers choose the best path
>  > > from source to destination which includes routing arould failure points.
>  > > 
>  > 	=> Yes that's fine, but MIP solves a problem that has to scale for 
>  > 	the whole Internet. 
> 
>    MIP does, HMIP does not.
> 
	=> Of course it doesn't. It is not meant to.
	Have you read the draft ???

>  >      Now there is an argument that once ou have 
>  > 	that solution and can also support local mobility with minor 
>  > 	extensions, is it really worth inventing something new ? 
> 
>    There's nothing new to invent for a routing protocol
>    to change the reachability of a host (or subnet) to
>    another router, as far as I know.
> 
	=> Well obviously you have it all worked out.

>  > 	Maybe, but there is no proof yet. All I'm hearing from you 
>  > 	is feelings. I admit the redundancy issue is important but 
>  > 	I think it's fixable.
> 
>    With routing based solutions, there's about, oh say,
>    going on 30 years of experience of how to deal with
>    failover and redundancy. It was extremely painful,
>    and continues to be extremely painful. Pardon me
>    if I view your "fixable" with healthy dose of
>    skepticism.
>    
	=> There are already protocols for router redundancy
	(eg VRRP).

	Hesham

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 27 Feb 2001 15:48:20 -0500

Boy, do I ever agree with you Andrew.

Gary

> From: Andrew T. Campbell [mailto:[email-masked]]
> Sent: Tuesday, February 27, 2001 12:55 PM
> To: 'Dana L. Blair'; 'Claude Castelluccia'
> Cc: 'Charlie Perkins'; Kenward, Gary [WDLN2:AN10:EXCH]; 
> seamoby; Andrew
> Campbell (E-mail)
> Some tangential issues:
> I still think vanilla Mobile IP with fast handoff (i.e.,
> Low latency Handoffs in Mobile IPv4) is a limited
> solution and in the end a patch - I think that is what Dana 
> is trying to say in a nice way. But I don't want to
> put words into people's mouths ;-) 
> 
> On another note:
> 
> I agree with Dana that tree like structures like HMIP, CIP, etc.
> are points of failure and lack robustness - this should be a key issue
> for seamoby not just going fast, context switch and paging.
> One could use per-host routes but not based on a single tree or
> a single gateway but a routed network with multiple gateways; 
> clearly I'm pointing to limitations in CIP here, and
> other proposals. When seamoby looks at the solution space then
> Hawaii is closer to what I would consider a good starting point.
> 
> Again, as I mentioned that the last meeting, MIP should not be
> pushed into every new problem space (and IETF wireless working
> group) with the implicit instruction and due pressure 
> to "make MIP work in this space". Seamoby should
> have a clean slate. The only issue being to interwork with MIP 
> and not use MIP as the base class for the solution. 
> 
> As a another aside, one has to make sure that one 
> does not end up with a telco style 3G IP network, however;
> with all that additional plumbing that limits scalability for IP.
> Clearly the "All-IP" vision is more a marketing spin that substance.
> Before you think I'm being rhetorical read those proposals. Stay pure
> stay IP!
>  
> 
> 
> > From: Dana L. Blair [mailto:[email-masked]]
> > Sent: Tuesday, February 27, 2001 4:25 AM
> > To: Claude Castelluccia; Andrew T. Campbell
> > At 09:51 AM 2/27/01 +0100, Claude Castelluccia wrote: 
> > >
> > >   
> > > Hello, 
> > >
> > I don't think Hierarchy is the solution for faster handovers. 
> >  Nailing down the
> > transport path for
> > a MN as various points only introduces more opportunity for 
> > failure while
> > possibly improving handover
> > spead but not gauranteeing an improvement in handover.  
> > Include more heirarchy
> > in the IP network
> > is simply duplicating the errors of the cellular network on 
> > the internet.  Peer
> > to Peer addressability is the
> > only scalable technique for large scale mobility.  Addressing 
> > various middle
> > man routers increases
> > the latency because optimal paths may not be used and 
> > decreases reliability
> > because a statefule
> > single point of failure is introduced into the network. 
> > 
> > If any heirarchy is needed then it should only be introduced 
> > temporarily for
> > the duration of
> > a handoff between ALn and ALn+1 where the MN IP address 
> > changes.  If the MN IP
> > address
> > does not change then heirarchy is not needed.  Maintaining 
> > network intelligence
> > outside of
> > handover window introduces unecessary complexity in the 
> > routing path and
> > unreliability.
> > 
> > thanks,
> > Dana
> > 
> > 
> > 
> > 
> > >
> > > regards, 
> > > Claude. 
> > >   
> > >>
> > >>   
> > <http://comet.columbia.edu/~campbell>http://comet.columbia.edu
> > /~campbell 
> > >>
> > >> > From: [email-masked]
> > >> 
> > [<mailto:[email-masked]>mailto:owner-seamoby@diame
> > ter.org]On 
> <http://www.inrialpes.fr/planete/>http://www.inrialpes.fr/planete/  
> > 
> > 
> > 
> > 
> > 
>

---

From: [email-masked]
Date: Wed, 28 Feb 2001 10:33:01 +0200

Hi James,

> I think 3GPP2 is making a strong effort to make their All-IP 
> network all IP. They even recently started an effort to rearchitect 
> their RAN to be all IP (whether it goes so far as to be connectable 
> to the Internet, we shall see, but they are trying).
> 
> 3GPP is another story. They have lots of lingering telephony 
> stuff around for various reasons.

As I'm somewhat involved with 3GPP & PP2, my feeling is that both 
networks will not be part of the Internet.  Vendors & operators
in both groups (hey, there is a heck of a lot of overlap in terms
of participants of these groups) are still trying for a walled-garden
business model. In the face of licensing fees, network costs & an 
possible economic downturn - operators & vendors both will be trying
to sell existing solutions.  

Helping to get correct IP networking solutions into these architectures
is not a bad idea, but is it the IETF's job?  I'd rather suggest that
any solution we find here in SeaMoby should scale, should be effective
and be a good 'citizen' of the Internet ...

my 2 cents ...
John

---

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

James, 

> >Pat:
> >
> >You are misinterpreting what I wrote.
> >
> >I never said 3G. I said that the last thing "All-IP" 3G
> >networks are is "All-IP". You'd agree with that I'm sure?
> 
> 
> I think 3GPP2 is making a strong effort to make their All-IP network all 
> IP. They
> even recently started an effort to rearchitect their RAN to be all IP (whether
> it goes so far as to be connectable to the Internet, we shall see, but they
> are trying).
> 
> 3GPP is another story. They have lots of lingering telephony stuff around
> for various reasons.
> 
	=> 3GPP is also aiming for all-IP, but it seems everyone has his /her
	definition of all-IP. The reliance on the MSC ....etc in the core network
	was removed in the first release of GPRS as a step towards all-IP.
	IP in UTRAN is also being introduced in Release 5 with a strong 
	emphasis on IPv6. The telephony stuff (interfacing to the PSTN!) is 
	handled by Media Gateways on the edge of the PS domain.

	Now we could all argue against one architecture or another but
	as far as running your network on IP goes (which is what both 3GPPs 
	claim to be all-IP !)  3GPP did that a long time ago.

	As far as mobility goes, the major differences between the two 3GPPs 
	IMO is that 3GPP2 still relies on the MSC and that 3GPP uses GTP
	while 3GPP2 uses the RP interface. Both have MIP in their architectures.

	Hesham