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<mailto:marco.lieb...@neclab.eu>> Date: Friday, July 11, 2014 8:59 AM To: "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto: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
