Hi Rute, De : Rute Sofia [mailto:[email protected]] Envoyé : mardi 18 mars 2014 15:00 À : SEITE Pierrick IMT/OLN Cc : Alper Yegin; Charlie P.; Weixinpeng; [email protected]; [email protected] Objet : Re: [DMM] Where to place mobility functions <was, Re: DMM WG next steps>
Hello Pierrick, by stating that the MAPs are closer to the optimal data path, we are advocating that the signaling should be in-band. >>it could be but CP/DP is also on the radar screen. Actually, the charter >>text is talking about "mobility functions", and not MAP; I think it is a good >>way to remain generic and to avoid focusing on a single solution space. MAPs work on the control plane. Is there a reason for this? Also, I do not understand why we need to make a distinction between "user" and CN. The distinction is between MN and CN which are both functionality (control plane) that reside on user-equipment, usually in customer premises... >> right, it is MN and CN. My understanding is that we want to stress that the anchor could be deployed closer to the communications endpoints (I prefer to talk about optimal path). However, many DMM solutions, currently on the table, place the anchor close to the MN; so to clearly remind that other deployment exist, MN/CN distinction is introduced ... just my understanding.... I actually prefer "close to the user", as this i) does not prevent solutions from being centralized or de-centralized; ii) does not block solutions that are as of today on the access; iii) allows for new solutions, user-based, and where functionality may be split among multiple nodes on the network (access, customer premises, etc) to exist... >> the user is implicitly assumed to be the MN, but the MN can establish a >> communications with a server, close to which we could deploy anchoring >> capabilities. So I prefer to keep MN/CN wording. BR Rute Sofia On 18-03-2014 12:43, [email protected]<mailto:[email protected]> wrote: I realize that I gave a very bad example of centralized control functions... In our context, we should rather talk about centralized mobility control function (with distributed DP function)... anyway, my proposal for text revision is still valid. De : dmm [mailto:[email protected]] De la part de [email protected]<mailto:[email protected]> Envoyé : mardi 18 mars 2014 12:04 À : Alper Yegin; Charlie P.; Weixinpeng Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : Re: [DMM] Where to place mobility functions <was, Re: DMM WG next steps> Hello, Distributing mobility anchors closer either to the MN or CN are both valid scenarios. But, maybe there are other optimal anchor location; actually, here, we are seeking to reach optimal routing by placing the anchor closer to the optimal data path. Also, we may also want to keep a centralized anchor, for example, reachability purpose; in this case, we could say that data path going via the central anchor is the "most" optimal, because of the reachability constraint. In CP/DP distributions scenarios, we may want to distribute DP function and keep centralized some CP functions (e.g. billing... yes, operators like this function :)). So, I think that anchoring location considerations should be more generic and should focus on datapath management. I'd suggest the following rewording: ------- OLD TEXT ------------ by distributing mobility functions more closer to the user and/or its corresponding nodes. ---------- NEW TEXT --------- by distributing forwarding functions more closer to the optimal data path; for example, closer either to the mobile user or the corresponding node. Pirrick De : dmm [mailto:[email protected]] De la part de Alper Yegin Envoyé : mardi 18 mars 2014 10:19 À : Charlie P.; Weixinpeng Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : Re: [DMM] Where to place mobility functions <was, Re: DMM WG next steps> Hello Xinpeng, In the legacy thinking, the mobility anchor is in the core network (centrally-located HA). That's the basic Mobile IP design. Now people are also considering placing anchors in the access network. And then there's one more possibility, which is to place an anchor near/on the corresponding node. Please see the Cnet-homing presentation for more: http://www.ietf.org/proceedings/87/slides/slides-87-dmm-2.pdf Questions/comments welcome. Charlie: Yes, we cannot assume there'll be an anchor on/near every CN. Our proposal takes that into account. In fact, today there's no anchor in every access network either. There's basically none in any WiFi network today. Both situation is subject to change based on DMM developments. Alper On Mar 18, 2014, at 9:08 AM, Charlie P. wrote: Hello folks, One difference is that a mobile node is likely to be located in a network that supports mobility, whereas the network hosting a general CN may not have any mobility support features. Regards, Charlie P. -----Original Message----- From: Weixinpeng Sent: Mar 17, 2014 11:59 PM To: Alper Yegin , Jouni Korhonen Cc: "[email protected]<mailto:[email protected]>" , "[email protected]<mailto:[email protected]>" Subject: Re: [DMM] DMM WG next steps Hi Alper, Is there any essential difference between placing the mobility function closer to the user and placing the mobility function closer to the CN? I think in some sense the user host and it's corresponding node are the same for mobility management protocol. So what's the reason to distinguish between them? BR, xinpeng From: dmm [mailto:[email protected]] On Behalf Of Alper Yegin Sent: Wednesday, March 05, 2014 9:04 PM To: Jouni Korhonen Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [DMM] DMM WG next steps Jouni, Thanks for the text. DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user. This part excludes the approaches that place the mobility function on or near the CN. I recommend the following revision: DMM can be used to realise such a distributed deployment model, by distributing mobility functions more closer to the user and/or its corresponding nodes. Alper On Mar 5, 2014, at 12:09 PM, Jouni Korhonen wrote: Folks, DMM WG has done some progress lately. The requirements document has already left the building and the gap analysis is heading to WGLC as we speak. It is about the time to think what we should do next now that we have grown out of the infancy. A smaller group of mobility enthusiasts have been discussing about possible next steps and how the possible new charter would look like. The current very draft text template can be found here: https://github.com/jounikor/dmm-re-charter As you can see, we are still in early stages and all input it welcome. Obviously, possible re-chartering depends on many things. For example, things like getting the gap analysis out of the WG and what the IESG says. Nothing has been fixed or decided yet. Anyhow, we will start the discussion on re-chartering with the expectation that the DMM WG will re-charter and continue developing new solutions and/or enhancements in the IP mobility space. - Jouni & Dapeng _______________________________________________ dmm mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmm _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmm -- Best Regards/Melhores Cumprimentos/mit freundlichen Gruessen, Rute Sofia .............................................. COPELABS - Association for the Research and Development of Cognition and People-centric Computing Direction http://copelabs.ulusofona.pt ......................................... _________________________________________________________________________________________________________________________ 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
