Re: Preparing for DMM future steps and rechartering

Hi Pete,


My definition of CP is between the AG and the MA, what is out there today.
Now, if there is a functional split of CP and DP on any entity, and if
there is a interface between those two in the form of some CP interface,
then I don't have a term for that interface. We can probably agree that
CP/DP split approaches are outside the scope of this discussions.


> I can still have an SDN-style network with a separate controller making
>policy decisions.

Ok. I understand now. Only the DP is moved, but the session CP state is
anchored on a central node ? I call that central node as a mobility
anchor, now if that anchor is in the data path or not is one
consideration. But, functionally, there is still a mobility anchor.




Regards
Sri



On 11/14/13 5:19 AM, "Peter McCann" <[email protected]> wrote:

>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
>
>
>