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" <peter.mcc...@huawei.com> 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 >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
