Subject: [DMM] Comments on draft-patil-dmm-issues-and-approaches2dmm-00

From: Peter McCann <[email-masked]>
Date: Tue, 6 Mar 2012 21:48:17 +0000

Hi, Raj, Carl, and Jouni,

I have some comments on draft-patil-dmm-issues-and-approaches2dmm-00.

I agree with most of Section 4, "Issues with current mobility models".  However,
I'd like to point out that existing networks are not just centralized in the manner
you point out, they also tend to have a hierarchical structure, e.g., the 
S-GW/P-GW split in 3GPP EPC.  Therefore, the issue you outline in Section 4.3
("Inefficient Routing and signaling overhead") is not quite true of the 3GPP
EPC, which can handle many mobility events in a localized manner similar to
HMIP.

The first paragraph of Section 7 talks about source address selection, and the
need to modify applications so that they request the kind of address that they
want.  I tend to think that applications will remain unmodified for some time
to come; however, most applications fit into the paradigm of opening short-lived
connections to a server and could be accommodated with some sort of automatic
handling in the MN's IP stack.

I found the last paragraph of Section 7 quite interesting.  I too think that there
is an important piece missing that you call "seamless mobility anchor relocation".
I think that the use of an interior routing protocol is spot on.  In fact, if you
read draft-mccann-dmm-flatarch-00, I propose just that.  I think we can use such
an anchor relocation protocol to make each access router in an autonomous system
(or smaller region of an autonomous system) a temporary anchor for a given prefix.
In my draft I propose running I-BGP on each AR and sending BGP UPDATES into the
network upon localized mobility events.  Such a protocol can also be used as a
substitute for the proxy ND technique that is currently specified to "grab" the
MN's packets at the HA.  By using a routing protocol, the HA can reach across
several routing hops so it doesn't necessarily need to be on the home link (which
can be the first AR to which the MN attached).  I think this would also enable us
to unify the authentication protocols used at the AR with the authentication protocol
used at the HA.  The ARs are just like HAs that don't have to tunnel the data anywhere
because the MN is locally connected.

Does it make sense to you?

--
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: Tue, 6 Mar 2012 22:05:12 +0000

Hi Pete,

Thanks for your review and comments. Let me come back to you with
responses in the next day or two.

-Raj

---

From: jouni korhonen <[email-masked]>
Date: Wed, 7 Mar 2012 08:57:15 +0200

Pete,

Thanks for the review. Some thoughts inline.

> S-GW/P-GW split in 3GPP EPC.  Therefore, the issue you outline in Section 4.3

It is quite common to run combined nodes. 

> EPC, which can handle many mobility events in a localized manner similar to

Could you clarify which functionality in EPC you refer to from IP point of
view?

> handling in the MN's IP stack.

I tend to think that developers who care and see some benefit for their
applications would update. Completely automated solution within the stack
would be nice but that also entails larger MN update and would also need
some additional (out of band) policy information to guide address selection.

> network upon localized mobility events.  Such a protocol can also be used as a

I yet need to read your draft properly.. but in general trying to solve
mobility issues with routing protocols is just moving the problems out
of your hands to others. You easily end up with uncomfortable amount of
host routes and your network being constantly in a "converging" state..

> because the MN is locally connected.

There are virtues for exploring the routing protocol "enslavement" for 
additional mobility management. Geo-redundancy would, for example, benefit
from it.

- Jouni

---

From: Peter McCann <[email-masked]>
Date: Wed, 7 Mar 2012 14:55:38 +0000

Hi, Jouni,

jouni korhonen wrote:
>> I agree with most of Section 4, "Issues with current mobility models". 
>> However, I'd like to point out that existing networks are not just
>> centralized in the manner you point out, they also tend to have a
>> hierarchical structure, e.g., the S-GW/P-GW split in 3GPP EPC. 
>> Therefore, the issue you outline in
> Section 4.3
> 

Sure, in that case the combined S-GW/P-GW is a centralized anchor
point and the excess signaling you point out in Section 4.3 would
indeed be a problem.

>> ("Inefficient Routing and signaling overhead") is not quite true of the
>> 3GPP EPC, which can handle many mobility events in a localized manner
>> similar to HMIP.
> 
> Could you clarify which functionality in EPC you refer to from IP point
> of view?

I mean the ability to update a local S-GW with each eNB change, which
avoids the extra signaling to the P-GW.  It is architecturally similar
to HMIP (really, PMIP + HMIP).

>> The first paragraph of Section 7 talks about source address selection,
>> and the need to modify applications so that they request the kind of
>> address that they want.  I tend to think that applications will remain
>> unmodified for some time to come; however, most applications fit into
>> the paradigm of opening short-lived connections to a server and could
>> be accommodated with some sort of automatic handling in the MN's IP
>> stack.
> 
> applications would update. Completely automated solution within the
> stack would be nice but that also entails larger MN update and would
> also need some additional (out of band) policy information to guide
> address selection.

It should certainly be possible for both models to co-exist.  If an application
specifies an address, that's great, but if it doesn't, maybe it should just
get a fixed privately scoped address that is then NATted out to whatever
public address the MN happens to have at the time the connection gets made.
 
>> I found the last paragraph of Section 7 quite interesting.  I too think
>> that there is an important piece missing that you call "seamless
>> mobility anchor relocation". I think that the use of an interior
>> routing protocol is spot on.  In fact, if you read
>> draft-mccann-dmm-flatarch-00, I propose just that.  I think we can use
>> such an anchor relocation protocol to make each access router in an
>> autonomous system (or smaller region of an autonomous system) a
>> temporary anchor for a given prefix. In my draft I propose running
>> I-BGP on each AR and sending BGP UPDATES into the network upon
>> localized mobility events.  Such a protocol can also be
> used as a
> 

We need to do some simulation/implementation experiments to see if this
is a problem.  Hopefully I'll have more to say on that soon.  But, intuitively,
the UPDATE just has to propagate one hop to the crossover router to be effective.
We don't need the whole network to be converged for packets to take the right
path toward the currently serving AR.

>> substitute for the proxy ND technique that is currently specified to
>> "grab" the MN's packets at the HA.  By using a routing protocol, the HA
>> can reach across several routing hops so it doesn't necessarily need to
>> be on the home link (which can be the first AR to which the MN
>> attached).  I think this would also enable us to unify the
>> authentication protocols used at the AR with the authentication
>> protocol used at the HA.  The ARs are just like HAs that don't have to
>> tunnel the data anywhere because the MN is locally connected.
> 
> additional mobility management. Geo-redundancy would, for example,
> benefit from it.

You would get all the benefits of distribution and fault-tolerance from
the routing protocol itself.  IP routing already has these features built-in.
It is the establishment of tunnel state in a single box that makes the network
fragile.

-Pete

---

From: jouni korhonen <[email-masked]>
Date: Thu, 8 Mar 2012 10:54:06 +0200

Pete,

> point and the excess signaling you point out in Section 4.3 would

Actually, signaling due a handover (SGW/SGSN relocation or even L2 handover)
in PGW/GGSN is not the biggest issue.. It is the bearer management in general,
which is not a problem for IETF to tackle. However, designing a system that is
conservative on signaling is a good general guideline. And that is the reason
we emphasize that. So not let us get too stuck with EPC, rather learn from it.

> to HMIP (really, PMIP + HMIP).

Comparing against HMIP is not that straight forward. In HMIP you have
IP exit points at AR, MAP and HA, also local mobility at the IP level
under MAP and L2 mobility under AR. With EPC, you have one exist point
at your gateway and L2 mobility under SGW.

> is a problem.  Hopefully I'll have more to say on that soon.  But, intuitively,

That would be excellent.

> path toward the currently serving AR.

You need to be careful on the deployment architecture you introduce
stuff like this. I am just being conservative ;) Once the constraints
and assumptions are better known it is easier to evaluate the solution.

- Jouni

---

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

Hi, Jouni,

jouni korhonen wrote:
>>>> I have some comments on draft-patil-dmm-issues-and-approaches2dmm- 00.
>>>> 
>>>> I agree with most of Section 4, "Issues with current mobility
>>>> models". However, I'd like to point out that existing networks are
>>>> not just centralized in the manner you point out, they also tend to
>>>> have a hierarchical structure, e.g., the S-GW/P-GW split in 3GPP EPC.
> Actually, signaling due a handover (SGW/SGSN relocation or even L2
> handover) in PGW/GGSN is not the biggest issue.. It is the bearer
> management in general, which is not a problem for IETF to tackle.
> However, designing a system that is conservative on signaling is a good
> general guideline. And that is the reason we emphasize that. So not let
> us get too stuck with EPC, rather learn from it.

I agree.

>>>> ("Inefficient Routing and signaling overhead") is not quite true of
>>>> the 3GPP EPC, which can handle many mobility events in a localized
>>>> manner similar to HMIP.
>>> 
>>> Could you clarify which functionality in EPC you refer to from IP
>>> point of view?
>> 

If you combine HMIP with PMIP (as I think some would propose) it starts
to look very similar to the L2 mobility provided by GPRS.

>> the UPDATE just has to propagate one hop to the crossover router to be
>> effective. We don't need the whole network to be converged for packets
>> to take the right path toward the currently serving AR.
> 

Yes we need to do a simulation and play with the parameters to find out
engineering guidelines for how to dimension the network.  But, I think that's
generally true of any solution.

-Pete