Re: Preparing for DMM future steps and rechartering

Hi, Marco, Sri,

I think that Marco's analysis works, in the sense that it places both
classes of solutions within a cohesive framework.  I am more doubtful,
however, that the two kinds of solutions would co-exist in the same
access network, as they both seem to implement a kind of local mobility
management.

Yes, Sri, I think this is a "re-anchoring" if we define the anchor as
the point to which IP packets are delivered by the routing infrastructure.
I don't see why you say there is no control plane; I can still have an
SDN-style network with a separate controller making policy decisions.
It is true that there is no single router that handles the user's traffic
for the life of the IP session, but I thought the point of DMM was to get
rid of such scalability and fault bottlenecks.

I am a little confused as to what is your definition of a control plane.
It seems you apply this term to the LMA, but in today's specs the LMA
is a combined CP/DP entity.

-Pete

Sri Gundavelli (sgundave) wrote:
> Hi Marco,
> 
> 
>> 
>> My intention is not to eliminate a tunnel that exists in any of the
>> tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM
>> primarily distributes topological anchor point for the MN's IP
>> address(es). Forget about the C-plane for now.
>> Tunnels apply solely below (well, towards access) such anchor.
>> If we distribute them to an extreme, they are placed on radio access
>> points and the tunnel disappears. Then we arrive at Pete's model. If
>> anchor points are somewhere above, say in the backhaul, the tunnel
>> remains at least between the anchor and some node in the access
>> (network based mobility mgmnt) or the MN (host based mobility mgmnt).
> 
> 
> Ok.
> 
> Distributing topological anchor points at the access edge can be done
> today without any new standards extensions. This is more about
> deployment and selection of a gateway at the access edge. But, any
> time the MN moves and attaches to a different point in the network,
> that tunnel and the CP is expected to be there between the previous
> home- anchor and the current access-anchor. But, here, the proposals
> hide the tunnel (at the initial attachment point and what can be
> argued as a home link and which is fine), but when the MN moves the
> session is re- anchored to a different gateway with a churn in the
> routing infrastructure and with major impact to policy plane. So,
> there is no tunnel and there is no CP in this model.
> 
> 
>> 
>> I think none of the proposals wants to discuss away the tunnels as per
>> MIP/PMIP. But above anchor level, regular routing applies to plain data
>> packets of the U-Plane. A key component for DMM, IMO, is how to
>> accomplish that routing towards the MN's current anchor point, even if
>> the anchored IP address is topologically incorrect. To accomplish this,
>> my intent is to not introduce tunnels above anchor level. So, it's not
>> about eliminating tunnels, but it is about not introducing tunnels
>> where never have been tunnels before :-)
> 
> 
> :) If you can show this working without re-anchoring the session to a
> different gateway, then I will agree. You see this from the point of
> view of IP routing, but I'm looking for that subscriber session which
> I'm not able to find.
> 
> Tunnels hide the topology and make that reachability work; it gives me
> a stable anchor point that my operator can manage my session.
> 
> 
> Regards
> Sri
> 
> 
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm