Hi, Just to be sure that we are on the same page....
De : dmm [mailto:[email protected]] De la part de Sri Gundavelli (sgundave) Envoyé : jeudi 17 juillet 2014 06:37 À : Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin Cc : [email protected] Objet : Re: [DMM] demand for DMM traffic steering Hi Marco, If there should be the use of word, "Anchor" in "access DPA" term is a minor issue, IMO. We can always fix that and come up with a better term. The key point is the distinction in roles and functionalities of these two entities and which we seem to agree. Home DPA is clearly the routing anchor and access DPA is entity that is providing some mobility support and it is also the first-hop router. We also need to highlight that the functional role is always in the context of a mobility session. The Access DPA may assume the role of Home DPA for one specific MN's session, while it may offer the Access DPA function to another mobility session. > If we bring in offload at an Access DPA, the Access DPA provides a different > IP address to the MN and becomes the Home DPA for traffic using that IP. The > role of the original Home DPA may be solely to determine which traffic to > offload at the Access DPA. When we discuss offload at the Access DPA, we should qualify this and state that this offload is for certain IP flows for a session anchored on a remote Home DPA. While there may be another session anchored on the same Access DPA for that MN (with the access DPA acting as a Home DPA for that local session), [PS] Access DPA and Home DPA should be considered as different network functions and not be confused with network entities. Using the term Anchor in Access DPA is not a minor issue IMHO, because it implicitly assimilates anchoring and traffic redirection function. Actually, we should talk about DPA, i.e. the node where IP address are topologically correct and data plane redirection (DPR): the termination of the traffic redirection in the access network. Now, let's consider the example above: the UE initiates a first IP flow , flow#1,using the address obtained from the DPA of its current access (DPA#1), i.e. using the local address... Here, no mobility support, no DPR coming into play... . Then the UE attaches to a new access, i.e. changes the first-hop router, and obtain an IP address from the DPA of the new access ( DPA#2). Flow#1 remains anchored to DPA#1 and dataplane is updated to the DPR of the new access. The DPR may, or may not, be supported by the first-hop router of the new access. The DPR may, or may not be collocated with the DPA function. Then the UE intiates a second flow, flow#2, with address obtained from DPA#2 as source address. The UE is thus served by two DPAs, each handling their own mobility sessions; mobility functions are DPA#1 and DPR for flow#1 and only DPA#2 for flow#2. What I want to stress here is 1) a UE can be served by more than one home DPA and 2) the DPR function comes into play only when mobility support is required, i.e. when the UE attaches to a new first-hop router. but that session will have not relation to the Home DPA of the first session and so making sure your last sentence above did not suggest that. Its strictly the UE choice on address selection for local offload. [PS] exactly, but the term « offload » is not appropriate IMHO. Here, we are more talking about "Dynamic mobility" where the UE uses either anchored or local address , depending on the mobility situation. On the aspect of session migration across Home DPA's you had a comment in one of your earlier emails. I see session migration as a tool used in very specific scenarios. When we migrate a session from Home-DPA-1 to Home-DPA-2, truly the session is completely migrated to the new Home DPA; even the routing infra is updated and that allows us to completely forget the previous Home-DPA where the session was previously hosted. For a mobility session, at a point of time, we have states in the Controller, Home DPA and Access DPA (optionally) and that's about it. Home DPA may have been changed, Access DPA may have been changed as well, but the state is always present in these three entities. Regards Sri From: Marco Liebsch <[email protected]<mailto:[email protected]>> Date: Wednesday, July 16, 2014 2:31 PM To: Sri Gundavelli <[email protected]<mailto:[email protected]>>, "Hirschman, Brent B [CTO]" <[email protected]<mailto:[email protected]>>, Alper Yegin <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [DMM] demand for DMM traffic steering Sri, please see inline. From: Sri Gundavelli (sgundave) [mailto:[email protected]] Sent: Mittwoch, 16. Juli 2014 15:32 To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin Cc: [email protected]<mailto:[email protected]> Subject: Re: [DMM] demand for DMM traffic steering Marco, If the idea is DP anchor relocation after every L3 mobility event, you have a single-node DPA model. The MN attach point at every location will take the Home DPA Role after each Relocation trigger. Any time you cannot relocate a Home DPA, you end with a two node Access/Home DPA model, which IMO offers nice flexibility with respect to when to initiate DP relocation and when to go with a two-node DPA model. Yes, that's close to the model I had in mind. Remain anchored at the DPA, which preforms mobility management. Then, at some point when it makes sense (not every L3 handover, but when e.g. the routing path can be optimized), relocate the DPA. The new DPA may provide a new, topologically correct IP to the MN, or may import and bind the previous IP if IP address continuity is required. In the latter case tailored routing rules for traffic steering are required. The role of the Access DPA in case the Home DPA performs mobility management I left aside so far, as it serves more as locator (access gateway). It's not necessarily an anchor in terms of mobility management, unless we talk about a hierarchy of mobility anchors. If we bring in offload at an Access DPA, the Access DPA provides a different IP address to the MN and becomes the Home DPA for traffic using that IP. The role of the original Home DPA may be solely to determine which traffic to offload at the Access DPA. With all this (the Access DPA becoming a Home DPA..) I am wondering if the Access DPA deserves the term Anchor. Also according to your description we only have Home DPAs, which bind an MN's IP and perform mobility management. The Access-thing is not an anchor until it performs offload, which makes a Home DPA out of it. Isn't it more a Data Plane Access Gateway until it becomes a real anchor? marco _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
