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
