Subject: [DMM] draft-mccann-dmm-flatarch-00.txt

From: Peter McCann <[email-masked]>
Date: Tue, 6 Mar 2012 14:36:54 +0000

Hi, all,

On Friday I submitted a new draft that outlines what I think is a novel
approach to mobility management in a totally flat network.  The draft
can be found here:

http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00

Abstract

   Today's mobility management schemes make use of a hierarchy of
   tunnels from a relatively fixed anchor point, through one or more
   intermediate nodes, to reach the MN's current point of attachment.
   These schemes suffer from poor performance, scalability, and failure
   modes due to the centralization and statefulness of the anchor
   point(s).  The dmm (Distributed Mobility Management) working group is
   currently chartered to investigate alternative solutions that will
   provide greater performance, scalability, and robustness through the
   distribution of mobility anchors.  This document is an input to the
   dmm discussion.  It outlines a problem statement for the existing
   mobility management techniques and goes on to propose (high-level)
   solutions to two of the most vexing problems: MN authentication and
   mobility management in a fully distributed, flat (non-hierarchical)
   access network.  These two aspects are often treated separately in a
   layered architecture, but we argue there are important advantages to
   considering how these two functions can work in tandem to provide a
   simple and robust framework for the design of a wireless Internet
   Service Provider network.

I'd like some time to present this draft during the meeting in Paris,
hopefully 15 minutes.

--
Peter J. McCann
Huawei Technologies (USA)
[email-masked]
+1 908 541 3563
Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ  08807-2863  USA

---

From: <[email-masked]>
Date: Wed, 7 Mar 2012 22:52:06 +0000

Hi Pete,

Interesting proposal and approach to mobility. A few comments below:

1. The I-D mentions that the scope of an address space is within that of
an autonomous system. Do you see this autonomous system as one that
encompasses an operators entire network? I am just trying to get an
understanding of how big this autonomous system is. Given that an operator
could be serving millions of mobile nodes, how large can this single
contiguous autonomous system be?

2. Is the eNB/BS the AR in the proposal (fig 2 for example)?

3. If the eNB/BS is the AR, do you foresee concerns with the amount of
updates resulting from MNs moving between eNBs/BS'?

4. You state that legacy/hierarchical mobility based solutions "suffer
from poor performance, scalability and failure point(s)". I think that the
current networks have proven to be capable of supporting fairly large
numbers of users/MNs. So I don't see scalability being an issue. And
similarly I don't know what is the benchmark against which you are
comparing performance either. Whether this architecture can scale further
to support billions of devices is of course an unknown and could be an
issue.

5. The I-D states: "In particular, we note that many MNs will
   not require a fixed IP address for the entire duration of their
   packet data session, as they will most likely be acting as clients
   and initiating short-lived connections to servers."

This seems to be contradicting the solution which results in the address
being registered in DNS and the reverse lookup by the target eNB/BS
whenever there is a handover. Would it not be preferable to have a
short-lived address as well as one that continues to exist beyond
handovers?

6. Fig 2 shows an architecture wherein the eNB/BS itself is the 1st hop
AR. Given the shrinking cell sizes (to increase capacity) the likelihood
of Handovers even at pedestrian speeds goes up. Why not allow for a level
of indirection? That would reduce the amount of signaling and reduce route
updates.

7. Authentication upon attachment to re-attachment to a BS every time
could become quite expensive even with advanced CPUs. I don't know how
efficient the proposal to use the new breed of auth algorithms are on
battery for example.

8. The I-D states: "Then the mobile node updates its home DNS server to
point from its hostname to the new address."

If an MN is moving at 70mph and doing handovers every few seconds/mins,
does this approach work? Given the RTT for the DNS update?

9. The handovers and the route updates that happen within an autonomous
system and/or across it are not entirely clear. Hope to see your
presentation and explanation at IETF83.

10. The idea of integrating authentication with mobility is good and
should enable faster handoffs.

The concept is interesting and I was wondering if you have any simulations
or results from such.

-Raj

On 3/6/12 8:36 AM, "ext Peter McCann" <[email-masked]> wrote:

>_______________________________________________
>dmm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmm

---

From: Peter McCann <[email-masked]>
Date: Thu, 8 Mar 2012 14:33:27 +0000

Hi, Raj,

[email-masked] wrote:
> understanding of how big this autonomous system is. Given that an
> operator could be serving millions of mobile nodes, how large can this
> single contiguous autonomous system be?

Strictly speaking, an autonomous system is the scope within which
the same AS number is used and within which I-BGP runs.  However,
the scope in which an address can remain assigned to an MN would
in reality be a subset of the AS, to be determined based on
an engineering trade-off between the amount of BGP UPDATES, their
scope, and the size of the routing tables you are able to maintain
on the one hand, and the overhead of getting a new IP address assigned
on the other.

> 2. Is the eNB/BS the AR in the proposal (fig 2 for example)?

Yes, that would be the idea.

> updates resulting from MNs moving between eNBs/BS'?

The UPDATEs only need to propagate up to the route reflector(s) if you
are moving within a cluster.  In that case, I don't think the update is
any more overhead than the tunnel migration that is done today under an
S-GW.

If you are moving between clusters, then yes, the update has to propagate
further.  Again, you need to make an engineering tradeoff in terms of
how far the UPDATEs are allowed to propagate vs. the overhead of getting
a new address.

> from poor performance, scalability and failure point(s)". I think that
> the current networks have proven to be capable of supporting fairly
> large numbers of users/MNs. So I don't see scalability being an issue.

The current solutions tend to lead to P-GWs/GGSNs with millions of
sessions homed on them.  While it is possible to build such animals with
massive investments in fault tolerant hardware, a more scalable approach
would be to distribute the state maintained into many smaller, cheaper
boxes.

> And similarly I don't know what is the benchmark against which you are
> comparing performance either. 

The main performance drawback is the sub-optimal routing back to the
anchor point.

> Whether this architecture can scale
> further to support billions of devices is of course an unknown and could
> be an issue.

Indeed.

> short-lived address as well as one that continues to exist beyond

The text you quote says "many"; it does not say "all".  Indeed, I think
we need to support both kinds of MNs.  The point is a softer one, in that
we need to do our engineering for the most common case and worry less about
the tail ends of the distribution.  That's how we get good performance
from the solution.  Those MNs that need a fixed address should be supported,
it's just that the longer you keep the address, and the more mobility events
that you have during such a session, the more overhead and routing table bloat
you get.  Nodes that periodically re-request a new, local address and deprecate
their old address are good citizens that help to reduce this overhead and
routing table size.  The paragraph just says there are likely to be many
nodes that are capable of this behavior, so it is likely we can keep the
routing table updates/sizes to a manageable level.

> of Handovers even at pedestrian speeds goes up. Why not allow for a
> level of indirection? That would reduce the amount of signaling and
> reduce route updates.

If by "level of indirection" you mean a tunnel from the old AR to the new
AR, that leads to some of the same drawbacks of the hierarchical architecture.
Packets would need to traverse the backhaul 3 times to reach the MN and the
old AR would become a single point of failure for that session.

> efficient the proposal to use the new breed of auth algorithms are on

This needs to be studied.  Caching the LTSS for frequently visited BSs
will be a big help here.
 
> does this approach work? Given the RTT for the DNS update?

You wouldn't do this on every handover, only when you get a new IP address/prefix
allocated.  That's the beauty of decoupling address assignment from mobility
management.

> presentation and explanation at IETF83.

Sorry if the text isn't clear.  It assumes a fairly intimate understanding
of how to configure I-BGP.  Hopefully my presentation slides will give you
a better picture of how it is supposed to work.
 
> should enable faster handoffs.

The integration is at two points:

1) using link authentication with the AR to trigger network-based routing updates;
2) using MIP authentication with the HA to trigger the same network-based routing updates

I hope we can work on standardizing both of these authentication steps to
use the same credentials and operate with minimal round-trips.
 
> The concept is interesting and I was wondering if you have any
> simulations or results from such.

Unfortunately not yet.  We are working on it.  Will keep you updated.

---

From: liu dapeng <[email-masked]>
Date: Fri, 16 Mar 2012 15:11:03 +0800

Hi Peter,

As we discussed offline earlier, I have a similar proposal which is
also rely on IBGP to update the routing system and thence allow the MN
keep its address unchanged even after handover. I have not submit the
draft for this upcoming meeting.

The difference is that my proposal does not relay on DNS. Since the AR
needs to do reverse lookup every time a MN attaches to it, it may
result in performance issue.

Another point is for the inital state, the prefixes could be
aggregated at the reflector and confine the routing update whin the
domain but after a period of time, many MNs would roam in the domain
and the prefixes would be diffcult to aggregate. To solve this one
option is to design a upper level router above all the domain
reflectors and by carefully address planning, to make all the MN's
prefix belong to that router.

The idea could be extended to not only depends on IBGP. more general
speaking, it allows mobility management interacting with routing
system and will result in several different alternative designs.

Besides authentication, there are many other aspects need to explore,
e.g: address management, billing system etc..

Regards,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Fri, 16 Mar 2012 17:45:25 +0800

Hello Peter,

One additional comment for section3: seems that  it is a key exchange
procedure instead of a authentication procedure?

-Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: Peter McCann <[email-masked]>
Date: Fri, 16 Mar 2012 14:25:21 +0000

Hi, Dapeng,

> result in performance issue.

There needs to be some way for the new AR to discover the prefixes
associated with the MN.  DNS seems to be a relatively easy and light-weight
way of doing that.

> prefix belong to that router.

You can have multiple layers of route reflectors.  The UPDATE can
be confined to the appropriate scope.

> system and will result in several different alternative designs.

Agreed, but BGP seems to offer the policy flexibility (with LOCAL_PREF)
that we need to ensure that the latest UPDATE is used by all the routers.

> e.g: address management, billing system etc..

In general I am striving for an architecture that is free of RADIUS
and Diameter.  Granted, I have only addressed the first A in AAA, but
I think there are good solutions for the other two As that won't 
require round-trips to the home network.

-Pete

>> On Friday I submitted a new draft that outlines what I think is a
>> novel approach to mobility management in a totally flat network.
>> The draft can be found here:
>> 
>>    point(s).  The dmm (Distributed Mobility Management) working
>> group
> is
>>    mobility management in a fully distributed, flat (non- hierarchical)
>>    access network.  These two aspects are often treated separately
>> in
> a
>> I'd like some time to present this draft during the meeting in
>> Paris, hopefully 15 minutes.
>> 
>> --
>> Peter J. McCann

---

From: Peter McCann <[email-masked]>
Date: Fri, 16 Mar 2012 14:26:03 +0000

Hi, Dapeng,

> procedure instead of a authentication procedure?

It is both an authentication and a key exchange protocol.  Either one
is useless without the other.

-Pete