Re: Preparing for DMM future steps and rechartering

Hi Sri,

>-----Original Message-----
>From: Sri Gundavelli (sgundave) [mailto:[email protected]]
>Sent: Donnerstag, 14. November 2013 06:22
>To: Marco Liebsch; Peter McCann
>Cc: [email protected]
>Subject: Re: Preparing for DMM future steps and rechartering
>
>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.

Depends. I assume that the session you describe is a mobility session (binding ID-Locator),
not a data session. If the mobility session remains anchored at the previous attachment point,
there will be a tunnel towards the new attachment point, which may serve
as MAG. Optionally, the new attachment point may provide a new anchor and an additional
mobility session, hence an additional HoA, which depend on the MN to handle multiple
IPs. Other approach would imply moving the MN's mobility session from the previous anchor/point of attachment
to the new one. Then there is at least no tunnel needed to forward packets from the previous
anchor to the new one. But the anchored HoA or HNP at the new anchor is topologically
incorrect. That means the routing plane above anchors can take care about delivering
downlink packets to the MN's current anchor. Agree that that's an impact to the routing policy
plane, but a valid approach to achieve more optimal routes. 

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

Without re-anchoring the previous mobility session at the new anchor means
the previous anchor remains involved in the packet delivery. I was talking about
the case where the previous mobility session will be transferred and anchored at the new
mobility anchor. Only that enables short delivery paths, as the anchor points of the
MN's IP address is close to the MN. But in that case the routing plane needs
to support packet delivery for that MN. So, either by introducing tunnels in the
routing plane (e.g. according to LISP), which I'd like to avoid. Or by using per-host routes.
Or by using address translation to a routable address, which delivers the packet
to the mobile's current anchor. 

>
>Tunnels hide the topology and make that reachability work; it gives me a stable
>anchor point that my operator can manage my session.

Sure, anchors as well as tunnels from that anchor to a locator should be kept. After
anchor relocation, the new anchor takes care about tunnel management to
deliver packets to the current MN's location. However, the routing plane above
anchor level may take care about delivering packets to the current anchor, which
is a prerequisite to allow the new anchor doing his job.

Greetings,
marco

>
>
>Regards
>Sri
>