Re: 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. 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...

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...

BR
Rute Sofia

On 18-03-2014 12:43, [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]
> *Envoyé :* mardi 18 mars 2014 12:04
> *À :* Alper Yegin; Charlie P.; Weixinpeng
> *Cc :* [email protected]; [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 J).
>
> 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]; [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]
> 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
.........................................

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm