Re: Preparing for DMM future steps and rechartering

Hi, Sri,


Sri Gundavelli (sgundave) wrote:
> Hi Pete,
> 
> 
> My definition of CP is between the AG and the MA, what is out there
> today. 

The "control plane" is an abstract term for a collection of entities,
one of which exists in each AG and MA.

> 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 would call that a CP-DP interface and I agree it's out of scope of
DMM.

In particular, PMIP is not a CP-DP interface protocol.

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

There can be (but does not have to be) a centralized control plane
element that has a global view of all the MNs currently attached
and keeps track of which MAG they are currently on.  From the point
of view of DMM, that's just an operational detail of a particular
deployment.  We certainly should not require the data plane traffic
to go through that node, and we should allow for mechanisms other
than tunneling to redirect packets to the new MAG after a mobility
event.  The centralized control plane (if it exists) can be involved
in setting up that redirection state, or a distributed routing 
protocol can take care of it.

-Pete



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