Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-reg-tunnel-01.txt

From: Charles Perkins <[email-masked]>
Date: Thu, 26 Aug 1999 09:10:26 -0700

Hello Pete,

You wrote:

>>I> http://www.ietf.org/internet-drafts/draft-ietf-mobileip-reg-tunnel-01.txt
>>                              ..........
>>1) I do not believe it can correctly handle MNs with private IP addresses.

Annika wrote:

> addresses. But hopefully it will work well together with whatever
> solution comes out of the discussions about private addresses.
> You are right, this draft does not address the problem of private IP

I wanted to reinforce Annika's point here.  Our intention was to
make a self-contained draft that could handle private addresses,
but which does not itself private addresses.  Making the separation
between the concepts was an illuminating and at times frustrating
process, which caused us to reject several alternative approaches
(and, in fact, in my cloudy recollection of Oslo it eventually
caused us to require the `I' flag ).

We feel that the regional draft can progress separately, but that
any such approach must be designed on the basis of the best current
understanding about how to handle private addresses.  So, for
instance, we believe that the current regional draft would be friendly
to any necessary extension for handling GRE tunnels, or for specifying
ways that foreign agents might taking home agent addresses into
consideration when delivering decapsulated packets.

Furthermore, we hope that such regional operations will be
taken into consideration as part of the inevitable discussion
about private addresses, so that as ideas emerge about private
addresses, people will also try to understand how regional
registration can work with private addresses.  The best way
to do this is to have an active effort for regional registration
going on at the same time.  For instance, if the home agent address
is important for routing packets to a mobile node, the GFA may
be required to change only the destination IP address of the IP
header when re-encapsulating packets for a lower-level care-of address.
Or, working group discussion may instead indicate the need for
an additional encapsulation, or a modified version of the minimal
encapsulation header, or ...?

>> 3) Security
>>                      .........
>> This draft seems incapable of leveraging any link-layer security that
>> may exist, such as in a cellular network.

This is an interesting observation, but isn't directly related
to regional registration.  Instead, I believe it is the departure
point for a very wide-ranging discussion about whether or not
Mobile IP itself is capable of leveraging link-layer security.

I think that mixing in link-layer security mechanisms with regional
registration mechanisms is mixing together operations from different
protocol levels in a suboptimal way.  On the other hand, it clearly
has applications in today's real world.

Regards,
Charlie P.

=============================================================

I am changing my affiliation.  My new e-mail address will be:
                Charles E. Perkins <[email-masked]>
I am also reachable at <[email-masked]>

=============================================================

---

From: Pete McCann <[email-masked]>
Date: Thu, 26 Aug 1999 14:37:36 -0500

Hi, Charles,

Charles Perkins <[email-masked]> (CP) writes:

>> You are right, this draft does not address the problem of private IP

CP> I wanted to reinforce Annika's point here.  Our intention was to
CP> make a self-contained draft that could handle private addresses,
CP> but which does not itself private addresses.  Making the separation
CP> between the concepts was an illuminating and at times frustrating
CP> process, which caused us to reject several alternative approaches
CP> (and, in fact, in my cloudy recollection of Oslo it eventually
CP> caused us to require the `I' flag ).

CP> We feel that the regional draft can progress separately, but that
CP> any such approach must be designed on the basis of the best current
CP> understanding about how to handle private addresses.  So, for
CP> instance, we believe that the current regional draft would be friendly
CP> to any necessary extension for handling GRE tunnels, or for specifying
CP> ways that foreign agents might taking home agent addresses into
CP> consideration when delivering decapsulated packets.

Ok, I hope we can agree on some mechanisms.

CP> Furthermore, we hope that such regional operations will be
CP> taken into consideration as part of the inevitable discussion
CP> about private addresses, so that as ideas emerge about private
CP> addresses, people will also try to understand how regional
CP> registration can work with private addresses.  The best way
CP> to do this is to have an active effort for regional registration
CP> going on at the same time.

Some vendors already claim to handle private addresses, with the
simple mechanism of using the HA address and MN link-layer address as
unique identifiers.  While not formally part of any standard, this
approach could easily be implemented by an otherwised RFC2002
compliant FA.  I think this is understood pretty well and I think we
should be careful not to break this approach when we separate FA from
GFA.

CP> For instance, if the home agent address
CP> is important for routing packets to a mobile node, the GFA may
CP> be required to change only the destination IP address of the IP
CP> header when re-encapsulating packets for a lower-level care-of address.

But a similar mechanism must be introduced for the reverse traffic
path.  An IP-in-IP encapsulated packet addressed from FA to GFA does
not contain enough information.

CP> Or, working group discussion may instead indicate the need for
CP> an additional encapsulation, or a modified version of the minimal
CP> encapsulation header, or ...?

GRE encapsulation? :)

>>> may exist, such as in a cellular network.

CP> This is an interesting observation, but isn't directly related
CP> to regional registration.  Instead, I believe it is the departure
CP> point for a very wide-ranging discussion about whether or not
CP> Mobile IP itself is capable of leveraging link-layer security.

Well, it is at least partly related to regional registration if some
information that is available to an RFC 2002 node is not available to
a regional GFA.

CP> I think that mixing in link-layer security mechanisms with regional
CP> registration mechanisms is mixing together operations from different
CP> protocol levels in a suboptimal way.

I agree that separation of concerns between layers is important, but
I'm not trying to write a protocol that violates modularity.  I'm
simply pointing out that some security properties depend on the proper
mapping of link-layer IDs to tunnels or IP addresses.  Security
concerns intrinsically violate layers - e.g., a firewall must be aware
of on which interface a packet arrived in order to implement policy.

CP> On the other hand, it clearly
CP> has applications in today's real world.

Yes.

I also hope we can get some idea from real-world vendors & carriers on
just how important it is to solve the "micro-mobility" problem in this
way: that is, at the IP layer, and in a way that's visible to MNs.
How big is the problem we are trying to solve?  How much extra
location management traffic/latency are we really talking about?  Keep
in mind that base stations do not terminate IP traffic in 2G or 3G
cellular networks - this is done further up in the network, meaning IP
handoffs are less frequent.

-Pete

---

From: Gerald Maguire <[email-masked]>
Date: Thu, 26 Aug 1999 22:09:23 +0200

Pete stated:
     Keep

While this was perhaps true in 2G, it need not be true for all
3G. Especially if basestations are connected via IP (such as in the
case of ICEBERG) - why should you carry all this traffic up to a few
choke points - rather than route it as directly as possible.

This is especially true for the case of picocellular cells (for
example at home) where much of the traffic might not even need to
leave the house if it could be gatewayed more directly. Consider the
case of GSM on the Net type installations in offices - where much of
the traffic will be within the company but perhaps to a device on
another type of link - why should it go back to an gateway out of the
company (even if the actually MSC functionality is not located at the
company's site -- since the mobility management traffic is much
smaller than the actual channel traffic it is feasible to provide a
local BTS infrastructure, but put all the HLR, VLR, etc. functions
elsewhere.). {Although I should point out that there is a two board
Ericsson AXE-10 equivalent called Hatchet or MicroMTX, see the
upcoming talk by Per Bergqvist, Ericsson Radio AB
         http://www.erlang.se/erlang/sure/main/news/euc99.shtml
Erlang is also used to implement the GGSN and SGSN for Ericsson's GPRS.
So potentially one could have a very compact 2G system.
}

In an environment where there is a mix of WLAN and 2G (or 3G) overlays
- the mobility will have to be handled at the IP layer - since the
link layers can't talk to each other directly.

So I am not convinced that the rate of handoffs will be all that
low. Considering that I walk through at least 3 different DECT
environments when I walk 150m to the nearest hot dog vendor - I would
expect that in the future there will be at least this number of Mobile
IP networks that I will walk through.

Chip

---

From: Pete McCann <[email-masked]>
Date: Thu, 26 Aug 1999 16:22:14 -0500

Gerald Maguire <[email-masked]> (GM) writes:

GM> So I am not convinced that the rate of handoffs will be all that
GM> low. Considering that I walk through at least 3 different DECT
GM> environments when I walk 150m to the nearest hot dog vendor - I would
GM> expect that in the future there will be at least this number of Mobile
GM> IP networks that I will walk through.

Ok, so perhaps I am being influenced by some of the architectural
biases of my current employer. :)

Anyway, most of the examples you gave were indoor or low-mobility
(walking pace) environments.  What will be the actual rate of handoff?
Won't vanilla Mobile IP (possibly with Previous FA extensions) be able
to keep up?

-Pete

---

From: Gerald Maguire <[email-masked]>
Date: Fri, 27 Aug 1999 00:01:27 +0200

Given that a reasonable walking rate is about 3m/sec (while a driver
on the interstate in NJ is perhaps moving 10 times this speed -- on a
good day) this means that for indoor picocells that I can walk through
some of them (such as a 10m cell) before I will have heard the second
Mobile IP beacon and in many cases before I can even get a DHCP
assigned COA (should I know that I have entered a new cell)! For
details of the COA timing measurments see:

    Jon-Olov Vatn and Gerald Q. Maguire Jr., "The effect of using
    co-located care-of addresses on macro handover delay", Fourteenth
    Nordic Tele-traffic Seminar (NTS 14), August 18 - 20, 1998, Lyngby,
    Denmark.

    which can be fetched from:  http://www.it.kth.se/~vatn/

Working in a building with multiple wireless infrastructures and with
a variety of access points (often with in a few meters of each other)
it is not hard to change which infrastructure provides you the best
service (in some cases without even moving yourself - but because
someone or something else has moved). So I think the rate at which you
can have intersystem handoffs is rather fast in comparison to some of
the current Mobile IP mechanisms.

Chip

---

From: Pete McCann <[email-masked]>
Date: Thu, 26 Aug 1999 17:43:59 -0500

Hi, Chip,

Gerald Maguire <[email-masked]> (GM) writes:

GM> Given that a reasonable walking rate is about 3m/sec (while a driver
GM> on the interstate in NJ is perhaps moving 10 times this speed -- on a
GM> good day) this means that for indoor picocells that I can walk through
GM> some of them (such as a 10m cell) before I will have heard the second
GM> Mobile IP beacon and in many cases before I can even get a DHCP
GM> assigned COA (should I know that I have entered a new cell)! For
GM> details of the COA timing measurments see:

GM>     Jon-Olov Vatn and Gerald Q. Maguire Jr., "The effect of using
GM>     co-located care-of addresses on macro handover delay", Fourteenth
GM>     Nordic Tele-traffic Seminar (NTS 14), August 18 - 20, 1998, Lyngby,
GM>     Denmark.

GM>     which can be fetched from:  http://www.it.kth.se/~vatn/

Yes, I read this when you posted it previously.  Maybe the lesson is
to fix the speed of DHCP, as suggested in the paper, or not to use
DHCP at all.

GM> Working in a building with multiple wireless infrastructures and with
GM> a variety of access points (often with in a few meters of each other)
GM> it is not hard to change which infrastructure provides you the best
GM> service (in some cases without even moving yourself - but because
GM> someone or something else has moved). So I think the rate at which you
GM> can have intersystem handoffs is rather fast in comparison to some of
GM> the current Mobile IP mechanisms.

If you consider the case of FA-COA, and
solicitation/advertisement/registration sent immediately upon
link-layer handoff, this is not so clear to me.

In any case, assuming we have the Previous FA functionality working,
we have already eliminated the latency of the FA-HA roundtrip from the
interval between handoff and data reception.  In this case
regionalized handoffs only contribute a reduction in traffic to and
load at the HA.  Maybe what is needed is not a hierarchical tunneling
approach but rather a way to regulate the rate at which location
updates are forwarded to the HA.

-Pete

---

From: Tom Weckström <[email-masked]>
Date: Fri, 27 Aug 1999 15:00:18 +0300

Hello all and Pete,

I am glad the new regional tunneling draft has had such a stimulating
effect on the discussions of Mobile IP mailing list. :-)

A hierarchical MIP is not a piece of cake, we all know that for sure.
I believe the hierarchical solution has its advantages that are worth
striving for regardless of the complex questions involved.

Pete, this one from your comments amazed me:

On Thu, 26 Aug 1999, Pete McCann wrote:

mccap >In any case, assuming we have the Previous FA functionality working,
mccap >we have already eliminated the latency of the FA-HA roundtrip from the
mccap >interval between handoff and data reception.  In this case
mccap >regionalized handoffs only contribute a reduction in traffic to and
mccap >load at the HA.

Eliminating the latency of FA-HA roundtrip is just one of the advantages
of the hierarchical model. I do not know the "Previous FA functionality"
very well, but I assume it doesn't provide the other advantages that the
hierarchical model has.

The reduction of signaling traffic is a very important advantage of the
hierarchical model.
Imagine, thousands of Mobile Nodes roaming in a congress center or at an
airport, for example. It would be too much asked to order people turn
their MNs off while they rush for presentations or their flights. This
kind of mobility would create quite a lot of signaling traffic. This
traffic would unnecessarily load both the agents of the MIP system and the
Internet in general, if non-hierarchical model was used.

One can always argue that all the services foreign and home agents
can be clustered or otherwise load balanced, but shouldn't we look for a
model where such tricks are no longer needed? Furthermore, this approach
would not save us from loading the Internet core with MIP signaling.

mccap >  Maybe what is needed is not a hierarchical tunneling
mccap >approach but rather a way to regulate the rate at which location
mccap >updates are forwarded to the HA.

You are right - partly. ;-)
Namely, we do need a method for reducing the number of location update
messages that travel through the Internet from foreign network to the HA,
but there already is a solution at hand - it is the hierarchical Mobile
IP. :-)

Comments are welcome.

Best regards,
                Tom

--
        Tom Weckström           Dynamics group
                                Helsinki University of Technology
                                [email-masked]
                                http://www.cs.hut.fi/Research/Dynamics/

---

From: Pete McCann <[email-masked]>
Date: Fri, 27 Aug 1999 09:54:52 -0500

Hi, Tom,

=?ISO-8859-1?Q?Tom_Weckstr=F6m?= <[email-masked]> (TW) writes:

TW> Pete, this one from your comments amazed me:

I certainly didn't intend to amaze anyone... perhaps I was a little bit
unclear.

TW> On Thu, 26 Aug 1999, Pete McCann wrote:

mccap> In any case, assuming we have the Previous FA functionality working,
mccap> we have already eliminated the latency of the FA-HA roundtrip from the
mccap> interval between handoff and data reception.  In this case
mccap> regionalized handoffs only contribute a reduction in traffic to and
mccap> load at the HA.

TW> Eliminating the latency of FA-HA roundtrip is just one of the advantages
TW> of the hierarchical model. I do not know the "Previous FA functionality"
TW> very well, but I assume it doesn't provide the other advantages that the
TW> hierarchical model has.

TW> The reduction of signaling traffic is a very important advantage of the
TW> hierarchical model.
TW> Imagine, thousands of Mobile Nodes roaming in a congress center or at an
TW> airport, for example. It would be too much asked to order people turn
TW> their MNs off while they rush for presentations or their flights. This
TW> kind of mobility would create quite a lot of signaling traffic. This
TW> traffic would unnecessarily load both the agents of the MIP system and the
TW> Internet in general, if non-hierarchical model was used.

My original point still holds - I named two advantages to the regional
schemes, and you haven't brought up any new ones.  One is eliminating
latency of a handoff (the time between handoff and traffic reception),
and the other is reduction in signaling messages across the global
Internet and at the HA.  I claimed above that the Previous FA
extension can be used to provide the first feature.  Now let's talk
about the second.

TW> One can always argue that all the services foreign and home agents
TW> can be clustered or otherwise load balanced, but shouldn't we look for a
TW> model where such tricks are no longer needed? Furthermore, this approach
TW> would not save us from loading the Internet core with MIP signaling.

I agree (partially) - I wasn't advocating that we increase the
capacity of the HAs to deal with increased traffic.  Let me point out,
though, that FAs are faced with all the signaling traffic even in the
regional schemes.

mccap>   Maybe what is needed is not a hierarchical tunneling
mccap> approach but rather a way to regulate the rate at which location
mccap> updates are forwarded to the HA.

TW> You are right - partly. ;-)
TW> Namely, we do need a method for reducing the number of location update
TW> messages that travel through the Internet from foreign network to the HA,
TW> but there already is a solution at hand - it is the hierarchical Mobile
TW> IP. :-)

Sure, these schemes are one way to reduce traffic, but there may be
others.  For instance, what if we added a flag to a registration
request that said, "don't propagate this request to the HA just yet".
These kinds of registrations would contain only the Previous FA
extension.  Then the MN could selectively (according to some
predefined rate) send registrations to the HA or the previous FA as
needed and according to whatever load the HA could handle.  This seems
like a much simpler approach than the hierarchical tunnels and also
eliminates the centralized GFA that must de-tunnel/re-tunnel all
traffic passing through it.

-Pete