Sri and Marco, Is any of what you are describing captured in the existing drafts? If so, please provide the pointers.
Alper On Jul 11, 2014, at 8:45 PM, Sri Gundavelli (sgundave) wrote: > Hi Marco, > > I think we may have to qualify the term "anchor". In our conf calls we used > the terms, Control Plane Anchor (CPA), Data Plane Anchor (DPA) with > Home/Access prefix tags. > > At the start of a session, the selected anchor assigns a topologically > correct address. The HoA/HNP for a mobile node's session is always > topologically anchored on that node. That anchor is the Home CPA/DPA > (Integrated case) and for the controller scenario, those functions are split > across two nodes. However, once the MN changes its point of attachment, then > the selected anchor for that attachment can be the Acces-CPA/Access-DPA in > relation to the home CPA/DPA. The session is still anchored on the home > CPA/DPA, but the access CPA/DPA is providing the CoA (pardon me, its your > locator per the LISP terminology, or our classic CoA) and the routing state. > However, this access CPN/DPN is also a Home CPN/DPN as the MN can create a > new session and may obtain a new HoA/MNP. > > The aspect of session relocation is relevant for the initial session and at > that point your case#2 comes into picture. At this point, we have a choice to > keep both Access CPN/DPN and Home CPN/DPN and apply traditional schemes for > forwarding traffic, or relocate the session to the new Access CPA/DPA and > make that as the Home CPA/DPN for the initial session. But, the access > CPA/DPA is always a local gateway (typically first-hop router) and so not > sure how the gateway selection can be relevant in this context. Gateway > selection is relevant in a two node architecture with access and home > anchors, and selection being about the home anchor. > > Regards > Sri > > > > > > > From: Marco Liebsch <marco.lieb...@neclab.eu> > Date: Friday, July 11, 2014 8:59 AM > To: "dmm@ietf.org" <dmm@ietf.org> > Subject: [DMM] demand for DMM traffic steering > > Folks, I would like to discuss the demand for DMM traffic steering as > preparation for > Toronto. > > DMM enables smart deployment and selection of network components serving as > User-Plane > anchor to the mobile node. The MN’s IP address or prefix (HNP/HoA) is > assigned to the selected > anchor and bound to the MN’s locator (CoA, pCoA, ..) > > Now, there are two cases: > > (1) Selected anchor is in the network of the MN’s HoA/HNP (topologically > correct address) > (2) Selected anchor is not in the network of the MN’s HoA/HNP (topologically > incorrect address) > > Case (1) is what IP mobility assumed so far. Default routes in the transport > network deliver the > packet into the network which hosts the MN’s assigned anchor. > > Case (2) can happen in 2 cases: > (a) MN gets assigned a new anchor mid-session but wants to keep its HoA/HNP. > That’s what has been > called so far anchor re-location > (b) MN has a stable IP address (e.g. profile-bound) but the network wants to > select an anchor > according to the requested service, i.e. anchor should be close to a local > server or CDN cache. > In that case the MN’s IP address will be topologically incorrect from the > very beginning of its > attachment. > > All cases (a) and (b) may require steering the MN’s traffic according to a > host policy, as the > route deviates from the default. > > First questions we may rise: > I) Are we on the same page regarding the above cases? > II) What comes first in DMM: IP address configuration or > anchor selection? > > Hope we can discuss some opinions ahead of the meeting. > marco > > > > > > _______________________________________________ > 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
