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 distin
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 Yegi
Hi,
Mobility issues are not specifically in MIF scope. So, as long as we are
talking about exposing mobility state, the I-D should be in DMM. Another reason
is that MIF is still discussing the generic MIF API, so, I'm not sure they can
go on the mobility area before a while.
Pierrick
>-M
On Mar 18, 2014, at 4:20 AM, Jouni Korhonen wrote:
> Folks,
>
> Triggered by the question from Behcet, we should come up with the
> milestones. Few proposals:
>
> o The deployment models and scenarios I-D is obvious.
> o Anchor selection I-D is obvious. Could we also bundle
> the re-anchoring
I agree, let's not mixup DMM API with MIF API….
On Mar 18, 2014, at 10:41 AM, wrote:
> Hi,
>
> Mobility issues are not specifically in MIF scope. So, as long as we are
> talking about exposing mobility state, the I-D should be in DMM. Another
> reason is that MIF is still discussing the gene
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
corre
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 centra
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:dmm-boun...@ietf.org] De la par
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 distinctio
Hi Rute,
De : Rute Sofia [mailto:rute.so...@ulusofona.pt]
Envoyé : mardi 18 mars 2014 15:00
À : SEITE Pierrick IMT/OLN
Cc : Alper Yegin; Charlie P.; Weixinpeng; dmm@ietf.org;
dmm-cha...@tools.ietf.org
Objet : Re: [DMM] Where to place mobility functions
Hello Pierrick,
by stating that the MAPs
Hi Behcet,
How do you mean to submit it as a solution draft to dmm? That is essentially
what I am already proposing.
Thanks - Fred
From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Sent: Monday, March 17, 2014 5:37 PM
To: Templin, Fred L
Cc: Jouni Korhonen; dmm@ietf.org; dmm-cha...@tools.iet
Hi Pirrick,
I agree with you that the anchoring location considerations should be more
generic. But for your suggested NEW TEXT, I think it's a bit of ambiguous
to say "closer to the optimal data path", and as my understanding what DMM is
trying to do is to eliminate sub-optimal routing path betw
12 matches
Mail list logo
