Hi Sri, Thanks for your prompt response. please see inline. From: Sri Gundavelli (sgundave) [mailto:[email protected]] Sent: Freitag, 11. Juli 2014 19:46 To: Marco Liebsch; [email protected] Subject: Re: [DMM] demand for DMM traffic steering
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. I thought that gets clear from my description, but you are right. This thread focuses on the data/user plane anchor. At the start of a session, the selected anchor assigns a topologically correct address. I guess you're referring to the mobility session, not the data session. Yes, that's today's procedure: Select (data-plane) anchor first, then assign an IP address which fits to the anchor's network. 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. I think it can be even the same CPA that controls multiple DPAs, whether it's the home or the access. About the terms: I like the identifier/locator terms as they apply to any mobility solution without taking a particular one (e.g. PMIP) as base line for a discussion. This is not LISP-specific. See, MIP maps an identifier (HoA) to a locator (CoA). Northbound to the HA, the HoA serves as both, identifier and locator assuming a topologically correct HoA at that anchor. Same for PMIP; or even Cellular IP, where the locator is an output port, or BGP, where the locator is a hext hop :) So I think this is suitable terminology to discuss DMM, in particular if we still differentiate the northbound and the southbound operation from a distributed data plane anchor viewpoint. Questions to answer are then how are packet routed to selected DPA in particular if the assigned HoA is topologically incorrect at the used DPA. The protocol southbound to the DPA may use any mobility specific transport, e.g. tunnel (to the locator :)) . The aspect of session relocation is relevant for the initial session and at that point your case#2 comes into picture. Yes, that was the rationale behind. 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. Moving a mobile's mobility state (binding a HoA to a locator) from a previous DPA to a new DPA is gateway relocation. Well, relocation of the data plane anchor. The control plane anchor will/may stay the same. Gateway selection is relevant in a two node architecture with access and home anchors, and selection being about the home anchor. Selection is an orthogonal problem. Of course an initial DPA and a target DPA must be selected during DPA relocation. But the mechanism to transfer binding context and to steer traffic to the new anchor is a different technology compared to selection. Then: If we think about the case 2b below, that implies that the initially selected DPA (is it the home DPA in your model?) binds a HoA which is topologically not correct from the very beginning. Here, traffic steering may be required from the first registration already. I am just wondering if there is a reasonable use case behind this. PI address binding? marco Regards Sri From: Marco Liebsch <[email protected]<mailto:[email protected]>> Date: Friday, July 11, 2014 8:59 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/dmm
