Subject: [MOBILE-IP] Darwinian evolution of proxy tunnelling...

From: "G. Ensuque" <[email-masked]>
Date: Mon, 16 Aug 1999 09:54:47 +0100

Hi all

This is just to test my understanding: could the insiders correct me if I am
wrong...

Am I right to assume the following Darwinian evolution path for the idea of
having 'daisy-chained' tunnels through proxies?

Hierarchical FA --> TEP --> regionalized tunnel mgt --> THEMA

Thanks

Guilhem
(the other one)

BT Labs

---

From: Pete McCann <[email-masked]>
Date: Tue, 24 Aug 1999 11:31:37 -0500

Hi, Guilhem,

"G. Ensuque" <[email-masked]> (GE) writes:

GE> Hi all

GE> This is just to test my understanding: could the insiders correct
GE> me if I am wrong...

GE> Am I right to assume the following Darwinian evolution path for the idea of
GE> having 'daisy-chained' tunnels through proxies?

GE> Hierarchical FA --> TEP --> regionalized tunnel mgt --> THEMA

I'm not sure I would draw the picture quite that way.  THEMA definitely
derives from TEP and is a form of hierarchical FAs, but I would say
that the recent "Regionalized Tunnel" draft is on a separate branch.
The key distinguishing feature is that of transparency.

THEMA was originally conceived to solve a techno-political problem of
separation of the cellular link-layer termination point from foreign
agent functionality.  It provides a nice interface to FAs that is
independent of the link layer used to access the network.  While it is
also (incidentally) capable of serving as a hierarchical or regional
mobility solution, I am not at all sure that such architectures are
really justified.  Every one of these drafts makes the claim that they
enhance performance and scalability, but given the likely coverage areas
of link-layer termination points in wireless networks, and given some
of the work pointed out by Gerry Maguire:

> The simulations which we have done have gone down to 10m sized cells
> and there does not seem to be excessive traffic for managing the
> mobility of the mobile hosts (see
> http://www.it.kth.se/~maguire/JT-Liu-lic-thesis.pdf
> and
> http://www.it.kth.se/~aschmidt/DA.pdf
> for more details).

I am not convinced that the complexity of tree-like "regional
mobility" solutions are really justified.

So maybe the Previous FA extension will be enough to provide fast
handoff.  You still might need something like THEMA, though, depending
on which vendors supply your wireless equipment vs. which supply your
packet network equipment, and which of them have Mobile IP expertise.

Also none of the regional registration approaches solve the problem of
latency when we move between different administrative domains.  For
that we need either agreements between adjacent domains that allow the
Previous FA extension to work, or changes in the underlying wireless
transmission technologies that allow simultaneous link-layer
connections to two different networks.  That way a new registration
could be set up before the old one is torn down.

-Pete

---

From: Jari T Malinen <[email-masked]>
Date: Thu, 26 Aug 1999 00:32:48 +0200

Hello, Pete and Guilhem

> Pete McCann wrote

I would also like to mention another important distinguishing point,
the separation of concerns. The regionalized tunnel mgmt. draft does
not seem to assume any special support from the link-level. What if we
want to set up heterogeneous networks where we do have localized
location updates among devices from multiple vendors and among
multiple link-level technologies spanning over multiple subnets among
multiple administrative domains using legacy equipment (we are using a
"legacy" network level, the IPv4, after all)? Can we do all these with
THEMA?  The regionalized tunnel draft seems not to be designed with
multi-organization support in mind, but its principles seem not
impossible to expand over organization borders. Also, the separation
of concerns might affect the ease of evolution in standards and
implementations, in particular when using open environments.

> > http://www.it.kth.se/~aschmidt/DA.pdf

These texts seem interesting, but returning to your point,
perhaps the amount of traffic caused by location management is not so much
an issue here as is the network latency between the FA and the HA.

> packet network equipment, and which of them have Mobile IP expertise.

I also hope we could have a very simple protocol.  Maybe your
consideration is true in some environments, but what if we add the
private networks, must we guarantee communication among all FAs that
are in separate private or protected access networks as might be
needed with the PFA extension? We might want to use private address
spaces for access point FAs just to minimize the use of public
addresses in the access network organization.

> could be set up before the old one is torn down.

I wonder if this is strictly true. In a WLAN environment we could
think of a nested organization, say a university, where a set of
laboratories have agreed on a set of link-level parameters that allow
for roaming on a "public-access" channel between independently
administered small organizations within/under a larger
organization. Simultaneous inter-organizational link-layer connections
could also be thought of when a MN has multiple network interfaces,
say a WLAN and a low-speed wide-area wireless access.  Or, consider a
set of small businesses in a business park. The hierarchical structure
could follow, say, the structure of the domain names with the GFA
provided by a "big" organization, or a common ISP. A hierarchical
solution seems feasible for such settings.

> -Pete

Regards,

--jari

Jari Malinen (http://www.cs.hut.fi/~jtm)
Researcher, HUT/CS Lab. Tel. +358 9 451 4774, fax +358 9 451 5351.

---

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

Hi, Jari,

>> The key distinguishing feature is that of transparency.

JTM> I would also like to mention another important distinguishing point,
JTM> the separation of concerns. The regionalized tunnel mgmt. draft does
JTM> not seem to assume any special support from the link-level.

By the way, neither does THEMA - it simply propagates a unique
identifier back to the GFA.

JTM> What if we want to set up heterogeneous networks where we do have
JTM> localized location updates among devices from multiple vendors
JTM> and among multiple link-level technologies spanning over multiple
JTM> subnets among multiple administrative domains using legacy
JTM> equipment (we are using a "legacy" network level, the IPv4, after
JTM> all)? Can we do all these with THEMA?

I don't think either of the proposals are intended to be used across
administrative domains.  THEMA was certainly intended to be used with
diverse link-layers; in fact it decouples the link-layer specific
equipment from the (somewhat complex) FA functionality with a fairly
simple interface.  In contrast, the leaf FAs in the regionalized
tunnel approach need to implement the whole range of FA functionality
including dealing with authentication servers - an area that is
rapidly changing, to say the least.

>> > http://www.it.kth.se/~aschmidt/DA.pdf

JTM> These texts seem interesting, but returning to your point,
JTM> perhaps the amount of traffic caused by location management is not so much
JTM> an issue here as is the network latency between the FA and the HA.

Yes, this latency is an issue, which is why we need the Previous FA
extension or networks that support simultaneous dual connectivity for
smooth handoff.

>> packet network equipment, and which of them have Mobile IP expertise.

JTM> I also hope we could have a very simple protocol.  Maybe your
JTM> consideration is true in some environments, but what if we add the
JTM> private networks, must we guarantee communication among all FAs that
JTM> are in separate private or protected access networks as might be
JTM> needed with the PFA extension? We might want to use private address
JTM> spaces for access point FAs just to minimize the use of public
JTM> addresses in the access network organization.

All the more reason to keep those FAs invisible to the MNs.  Think
about it - do you really want your first-hop IP router to have a
private address, when you are accessing the public Internet or a
private network with a completely different address space?

-Pete

---

From: Jari T Malinen <[email-masked]>
Date: Sat, 28 Aug 1999 04:59:36 +0200

Hello, Pete

First, let me state that I find your design elegant in simplicity and
that I still have wishes for improvement for the regional tunneling
(not to speak of our implementation). However, I still also have
questions about your design.

> identifier back to the GFA.

Correct me if I am wrong, bud doesn't it occur in THEMA that a lowest
SFA forwards packets based on link-layer address of the MN? Is this
not against requirements for IPv4 routers?

Longer explanation: My earlier term "Special requirements for the
link-layer" is perhaps inaccurate. I mean there is the requirement for
first-hop routing to be based on link-layer addresses (and isn't the
possibility to support private MN addresses with FA decapsulation on
the same link based on this?).  Put in implementor's terms: at least
in Linux's IPv4 "policy-based routing" that has comments on being "as
specified in RFC 1812" (Class trees in Chap. 5.2.4.3), it seems
problematic (but maybe doable) to have rule-based routing using a link
address.  Is it not the case that RFC 1812 does not require
link-address-based routing from conformant routers but rather
separates the concerns there?

Another question stemming from the use of link-layer in identification
of the endpoint in THEMA: FA caches the bindings by a link-layer address
identifier.  If we tech-roam between two SFAs connected to the same FA,
e.g. from DSSS WLAN to IrDA so that our link-address changes, do we not
experience the FA-HA latency in THEMA while not in the regional tunneling?

> rapidly changing, to say the least.

Maybe, though the use of CAs should probably not be a requirement but
an option used when the policy of the access network needs AAA-based security?
The machinery could be thought to be there for making multiple alternatives
for security and configuration (we need not change implementation when
splitting/joining components to regional structures, a very simple
reconfiguration of a similar component is sufficient, this from the
"administrator's point of view").. When speaking of logical components, I
think you are right, the lower FA as such may have less use for some
parts of the FA functionality.

> extension or networks that support simultaneous dual connectivity for

Yes we may use both of these, or hierarchies, or a combination of them.
They reflect different approaches with pros and cons in both, perhaps?
Regional tunneling, by the way, can be used with the route optimization.

> private network with a completely different address space?

True, a first hop address can hide a public address, if any private
intranet address. But, if we want to conserve addresses, maybe a
private Internet-address (local?), e.g. 10.*.*.*, can be reused
several times over as the first-hop address with no danger for
ambiguity for public-network Mobile IP, while a similar range could
be defined a "private" intranet subspace (i.e. when the CN is from
an intranet).

Regards,

--jari

---

From: Pete McCann <[email-masked]>
Date: Mon, 30 Aug 1999 11:38:00 -0500

Hi, Jari,

JTM> Correct me if I am wrong, bud doesn't it occur in THEMA that a lowest
JTM> SFA forwards packets based on link-layer address of the MN?

Essentially you are correct: the link-layer address is mapped to a
TunnelID.

JTM> Is this not against requirements for IPv4 routers?

It may be, but those SFAs are not really routers.  In general I think
it would be more helpful if the Mobile IP community realized that FAs
are more like NASes than like routers.

JTM> Longer explanation: My earlier term "Special requirements for the
JTM> link-layer" is perhaps inaccurate. I mean there is the requirement for
JTM> first-hop routing to be based on link-layer addresses (and isn't the
JTM> possibility to support private MN addresses with FA decapsulation on
JTM> the same link based on this?).

Yes.  For an implementation to properly support private MN addresses,
it must use link-layer demultiplexing to distinguish packets.  This
shouldn't be a new concept for any NAS that implements tunneling.

JTM> Put in implementor's terms: at least
JTM> in Linux's IPv4 "policy-based routing" that has comments on being "as
JTM> specified in RFC 1812" (Class trees in Chap. 5.2.4.3), it seems
JTM> problematic (but maybe doable) to have rule-based routing using a link
JTM> address.  Is it not the case that RFC 1812 does not require
JTM> link-address-based routing from conformant routers but rather
JTM> separates the concerns there?

Again, maybe it's improper to try to use a general purpose IP routing
engine for this piece of the architecture.  We are building access
servers, not routers.

JTM> Another question stemming from the use of link-layer in identification
JTM> of the endpoint in THEMA: FA caches the bindings by a link-layer address
JTM> identifier.  If we tech-roam between two SFAs connected to the same FA,
JTM> e.g. from DSSS WLAN to IrDA so that our link-address changes, do we not
JTM> experience the FA-HA latency in THEMA while not in the regional tunneling?

You are correct that such a movement would need to be visible to the
MN, in contrast to movements on the same link technology.  This would
be a new appearance of the MN requiring a new registration.  However,
the FA-HA latency might be avoided by using other mechanisms.

>> In contrast, the leaf FAs in the regionalized

JTM> Maybe, though the use of CAs should probably not be a requirement
JTM> but an option used when the policy of the access network needs
JTM> AAA-based security?

Some form of AAA will be needed for commercial deployment scenarios
such as cellular networks.  Service providers like to get paid for
usage of their network.

JTM> The machinery could be thought to be there for making multiple
JTM> alternatives for security and configuration (we need not change
JTM> implementation when splitting/joining components to regional
JTM> structures, a very simple reconfiguration of a similar component
JTM> is sufficient, this from the "administrator's point of
JTM> view").. When speaking of logical components, I think you are
JTM> right, the lower FA as such may have less use for some parts of
JTM> the FA functionality.

Right - I am speaking also from an equipment manufacturer's point of
view.  The leaf devices are made by someone who understands the access
technology, such as wireless links.  The FAs should be made by someone
who knows & can keep up with the emerging AAA, VPN, and Internet
roaming technologies.  It may be desirable to decouple these
components, even when no IP-layer micro-mobility is needed.

>> do you really want your first-hop IP router to have a

JTM> True, a first hop address can hide a public address, if any private
JTM> intranet address. But, if we want to conserve addresses, maybe a
JTM> private Internet-address (local?), e.g. 10.*.*.*, can be reused
JTM> several times over as the first-hop address with no danger for
JTM> ambiguity for public-network Mobile IP, while a similar range could
JTM> be defined a "private" intranet subspace (i.e. when the CN is from
JTM> an intranet).

Will a MN be able to do proper movement detection, if two consecutive
FAs have the same address?

I don't think it's wise to place a restriction on the addresses that
can be used by intranets just so we can make this scheme work, if
that's what you are suggesting.  It seems to me we should just handle
the traffic properly in the first place.

-Pete

---

From: Jari T Malinen <[email-masked]>
Date: Wed, 1 Sep 1999 00:34:50 +0200

Hi, Pete,

> JTM> Is the link-level routing not against requirements for IPv4 routers?
>
> .. I am speaking also from an equipment manufacturer's point of
>> [Private addresses in leaf FAs]
>

The _requirement_ that all regional-aware access points would do
link-level routing would raise the bar for Mobile IP deployment on the
datacom networks.  Given that virtually all current host-routers would
either need custom routing engines or simply would not be acceptable
alternatives for custom hardware access points would make such
deployment expensive.  To become the great unificator between the
telecom and datacom worlds, means to ensure popularity in the latter
should also be considered.

Also to require strictly correct use of leaf FA addressing makes it
hard to do large picocellular environments with Mobile IPv4 due to the
need for either customization of all the leaf routing engines or too
many public addresses. I could imagine using a private/local network
among my desktop IrDA devices (without having a customized routing
engine on all those with FA) if I can guarantee no conflicting
addresses exist there.

I think the vast variety of possible setups where Mobile IP might be
of use do make the case for alternative approaches, at least for the
moment. So maybe we are making "Darwinian" comparisons of cats and
dogs when both currently have their place in the ecosystem :-)

Regards,

--jari