Subject: RE: [seamoby] micro, schmicro

From: [email-masked]
Date: Wed, 17 Jan 2001 11:03:23 +0200

Hi all,

I don't know, if this helps at all, but I thought I might share some of my
(not too distant) earlier experiences in mobility work on H.323 systems.
First of all, I have never seen a good definition for micro and macro
mobility. Yet people use these as if they were clearly and similarly
understood by everyone. If you ask me, micro mobility in the context of IP
networks is something that happens behind an access point or a base station,
i.e. no change of the CoA is involved and thus there isn't much (anything?)
that needs to be done in the IP layer. However, as I said, I'm sure there
are other definitions for micro mobility as well.
What we did in the H.323 Mobility work was not to use these terms, but
instead refer to the scope of the mobility in terms that were already
defined for H.323. Thus we ended up talking about intra-zone, inter-zone,
intra-domain and inter-domain mobility. In a similar manner, I would imagine
that terms, such as "intra/inter-link mobility", "intra/inter-subnet
mobility", "intra/inter domain mobility" or something similar could be used
with regards to Mobile IP and Seamoby. An alternative for this would, of
course, be to define unambigiously the terms "micro mobility" and "macro
mobility", but since these are already in use and mean various different
things depending on the context, I would imagine that the use of them would
lead to misunderstandings.

Just some thoughts of a previous lurker on the list...

------------------------------------------------
Jaakko Sundquist           * 
+358 50 3598281            * Audere est Facere!
[email-masked] * 
------------------------------------------------ 

> Um, actually what subnet you are on has an intimate relationship to
> what edge router you are using or what core router. The whole point
> of having a router is to bridge two subnets, in subnet based routing.
> 
> James,
> 
> I understand this.  However, it may be the case that useable 
> routes exist
> between
> an edge router pair that are unknown to the mobility agents 
> being used.  If this
> is
> the case the path between the mobile and the new ER is 
> shorter when the mobility
> agents are bypassed.  This will not always be the case, but 
> the worse case is
> that
> you have to route back through the mobility agents right?  
> Ideally wireless
> networks
> that handover to each other frequently will become mesh 
> networked at the edge of
> the big I overtime.  That is we follow the simple principle 
> of allowing the
> physical
> network to adapt overtime to the logical traffic patterns.
> 
> -Phil
> 
> 
> 
> 
>

---

From: Phil Neumiller <[email-masked]>
Date: Wed, 17 Jan 2001 07:39:33 -0600

> are other definitions for micro mobility as well.

You are correct.  This seems to be the running definition or what I have
called the "classic" definition of micro-mobility.  Now I have
questioned
whether this distinction is a useful one.  My feeling is that edge
versus
core mobility is a far more important distinction than a change in
subnet.

Also, I believe edge mobility is active ALL the time, and core mobility 
(mobile IP) is active WHEN subnet boundaries change.  Also, I believe
that edge mobility must compensate for the latency of adjustments in
core
routing updates made by mobile IP.

So, as I have stated in every design team message list, I hope we can 
convince the list to abandon this terminology and recognize the real 
problem which is edge versus core.  Complex behavior enabling seamless
mobility will be best implemented in edge devices of the global
Internet.
This is the ONLY way that it will scale globally.  As Tom Petty said,
"No, I won't back down.." on this one.

> lead to misunderstandings.
Here I would prefer we use the terminology of edge versus core mobility.
Can somebody shoot me down so I can get off this mantra??? :-)

TNX,

Phil (N9FCW, PSK/QPSK mbox = 10.140.700 MHz)

---

From: "Dana L. Blair" <[email-masked]>
Date: Wed, 17 Jan 2001 08:54:15 -0500

Let's take this discussion back to the micro-mobility alias, since it is a mobility
discussion.

>core mobility is a far more important distinction than a change in

Edge and Core are too abstract terms to discuss detailed mobility solutions.
Cellular folks use the term Core to reference an MSC, HLR, other other systems.
IP folks use the term Core to referece a high speed backbone IP network.
Since we are within the IP context let's use specific IP terms.  That is
why I defined micro-mobility in terms of IP addressing an Access Links.

>(mobile IP) is active WHEN subnet boundaries change.  Also, I believe

I think you need to define subnet more specifically.  For example, an ethernet
is an IP subnet which is part of a larger IP subnet for a department which
is part of a company IP subnet which is part of an ISP IP subnet which is
part of the internet.  Which subnet boundary are you referencing ?

I tried to avoid the subnet ambiguity by saying there are some boundaries where
the routable IP address assigned to the MN must change.  Then there are others
where it does not change.  micromobility applies to those cases where the
address does not change.

>"No, I won't back down.." on this one.

I don't think we disagree.  This design team is focussing on mobility solutions
that can be implemented at the edge of an IP network where the IP address
does not change.

Let's discuss on the call today.

thanks,
Dana

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 17 Jan 2001 08:14:18 -0800

Hello,

This note is a response to Dana (mainly) and to Phil.  I've
deleted individual names from the To: list, since I reckon
you'd get it from the main list...

>>  ==  Phil
>   ==  Dana

>> versus core mobility is a far more important distinction than a change in
>> subnet.

The mobile node itself shouldn't have to know anything more
than whether a node is an access router (what I'd like to call
a default router) or some other serving agent.  I specifically
didn't say "mobility agent", because I agree that [seamoby]
should stay out of the routing area.  On the other hand, I
reckon that edge and core routers implementing a [seamboby-mm]
protocol will have to know more than the mobile node knows.

> Edge and Core are too abstract terms to discuss detailed mobility solutions.

Not necessarily!  Edge is pretty clear.  Core could be "not edge".
That would be pretty clear.  Plus, I didn't see anyone making confusion
about it yet on this mailing list.  The term "micromobility", on the
other hand, almost guarantees confusion.

If there were a hum to find a term to replace "micromobility",
I'd certainly join the noise.

> part of the internet.  Which subnet boundary are you referencing ?

I've never seen this pointed out as a subnet ambiguity before!

The term "network" _MAY_ be considered ambiguous.  The term "subnet",
while technically subject to the ambiguity that you allude to, seems
never to have the problem in practice.  That would be especially true
in this case, since almost everyone seems to understand that "subnet"
refers to the part of the network where all the nodes are served by
the same default router.  In this case, it would/should probably be
"by the same access router".

> where it does not change.  micromobility applies to those cases where the

If the IP address doesn't change, then you'll end up installing
tunnels and host routes.  In the first place, that's a routing
problem.  In the second place, you'll very likely end up rediscovering
all the work done in [mobileip] for regional and hierarchical
mobility.  Alternatively, you could end up with something
with scalability problems, security problems, or very limited
applicability.  While scalability problems would not be
as important as usual, they will still translate into an
effective loss of capacity at the access routers.

While going through this process, it would be possible to make
a valuable contribution by studying and solving the QoS problems.

>> "No, I won't back down.." on this one.

Stand up, Phil, and thanks.  Even if I'm the only other one,
I do appreciate that someone else is saying that the terminology
is bad/harmful.

> Let's discuss on the call today.

I can't make the call, unfortunately, but I'll be interested to find
out how you can do that without messing with the route tables.

I left the main [seamoby] mailing list as the recipient
instead of restricting it to [seamoby-mm], since the issues
seem to be pretty fundamental -- but if others disagree I'll
happily restrict future messages.

Regards,
Charlie P.

---

From: "Dana L. Blair" <[email-masked]>
Date: Wed, 17 Jan 2001 11:44:01 -0500

>never to have the problem in practice.  That would be especially true

I am glad you agree with the "technical" ambiguity of subnet.

>"by the same access router".

Seems the subnet has several definitions:
1.  Yours above.
2.  All protocols below IP as defined in draft-ietf-pilc-link-design-04.txt.
3.  An IP network (subnetwork) that is part of a larger IP network
	designated by the prefix or netmask.  (what I was referencing).

>problem.  In the second place, you'll very likely end up rediscovering

Hopefully tunnels OR host routes and not both.  I agree that it is a routing
problem.

>mobility.  Alternatively, you could end up with something

You may be correct.  However, since all protocols except the
Mobile IP protocol have been out of scope for the Mobile IP
working group, then SEAMOBY is looking into it.  Why didn't you
object formally to the micromobility Design team creation if you
think it has no purpose or was in the wrong place ?  

>effective loss of capacity at the access routers.

That may be true.  But we might also come up with a good solution
too.

>a valuable contribution by studying and solving the QoS problems.

I think consensus of our Design Team is that the QoS attributes of
potential new access links should be part of the handoff decision
process.

>out how you can do that without messing with the route tables.

Who said we weren't going to change the routing tables ?  We are
just now defining the problem statement.  We will begin exploring
solutions which will probably fall into the following categories:
1.  Host Route Summarization/Desummarization
2.  Layer 2 tunneling
3.  Layer 3 tunnelling
4.  Multicasting

Hopefully, we can arrive at one solution.   Luca Salgarelli brought up the following idea
our conference call today and I agree with it. 

paraphrase from Luca:
 Mobility solutions that require tunnelling may impose unnecessary complexity where
mobility is only required within in a limited scope. 

My comment on Luca's comment:
An example of limited scope might be a single administrative domain with multiple
IP subnets and multiple access technologies.
Tunnel termination and QoS over tunnels may be more complex that 1 or 4 but that
remains to be worked out in the micromobility solution discussion.

thanks,
Dana

>happily restrict future messages.

Please restrict feature messages to micromobility  We can debate this on the
micromobility alias.  I have said these things before on that
alias.

thanks,
Dana

---

From: Jonathan Taz Mischo <[email-masked]>
Date: Sun, 21 Jan 2001 19:25:40 -0600

> I do appreciate that someone else is saying that the terminology

With this I will happily agree.  Too many people on this list are thinking
within the old boxes and are forgetting that we NEED to break the mold here, so
that we can come up with something that truly solves all the problems
gracefully.

Ciao!
-Jon

-- 
Jonathan "Taz" Mischo                     ph: +1.847.632.4039
Lead Software Engineer                    mn: +1.815.302.3505
Advanced Systems Technology Department    fx: +1.847.435.9970
Network Sector                            em: [email-masked]
Motorola, Inc.                            hp: http://www.refcode.org/taz/