Hello,
Thanks for the review. Please see inline.
Pierrick
-----Message d'origine-----
De : Jong-Hyouk Lee [mailto:[email protected]]
Envoyé : lundi 5 décembre 2011 10:50
À : SEITE Pierrick RD-RESA-REN; mext
Objet : Comments on "draft-seite-mext-dma-00"
Dear authors,
I read the draft "draft-seite-mext-dma-00" and have comments/questions:
1. The mobility support described in the draft seems for client
mobility. In other words, it's hard to apply the suggested dynamic
mobility anchoring scheme into a node dedicated for continuous services
to clients.
Actually, the solution applies to network based mobility management. The I-D
describes the deployment of PMIPv6 in a distributed fashion.
2. In the suggested dynamic mobility anchoring scheme, data packets of a
communication session established in a previous access network (MAR1) is
forwarded from MAR1 to the current MAR. This data packet forwarding must
be continuous as the address used in the communication session is
continuously used. Note that the MN is not only the communication
session initiator, but the CN could be.
Right, we have still to address incoming communications.
The data packet forwarding must
impact the whole network performance as the session duration is longer,
session is heavier, or mobility is higher.
3. Since the suggested dynamic mobility anchoring scheme allows the MN
to send/receive data packets having different network prefix compared
with that of the current access network, I'm not sure if the suggested
one properly works in existing network security mechanisms. For
instance, authors should address conflicts over ingress filtering
mechanisms.
Agreed.
4. Since the suggested dynamic mobility anchoring scheme allows the MN
to establish a communication session with its CN via a new address
obtained in a new network. In other words, 1) the MN establishes its
communication session with the CN via HoA1 at MAR1; 2) when the MN moves
to MAR2, it possibly establishes a new communication session with the CN
via HoA2 at MAR2 in order to avoid the overhead of data packet
forwarding. This means that even if the MN wants to keep the same
communication session with the CN, it must be re-establishes, i.e.,
making a new communication session with the CN.
No, in that case session continuity is ensures as per PMIP where MAR1 and MAR2
play respectively the LMA and MAG role.
In addition, making the
new communication session requires security operations again between the
MN and CN. Authors should think the cost in handovers: continuous
communication session maintaining vs. new session establishment.
Actually, I'm not sure to understand your point...
5. Could you describe little bit more about the entity storing the
session DB for all MNs? Hummm...we're talking about DMM,
but the entity is a centralized entity in an architectural view; all MARs
contacts for
MN's session information.
Here we are going on the separation of the control plane and data plane. The
data plane is distributed while a part of the data plane is centralized for
localization purpose. Several approaches are possible and have been described
in http://tools.ietf.org/html/draft-yokota-dmm-scenario-00: fully distribution
and partially distribution are both possible. With Fully distributed MM, both
control and data planes are distributed while partial distribution focuses on
distribution on the data plane (arguing that The volume of data traffic is much
higher than that of control traffic). MN's localisation is an issue in fully
distributed mobility architectures; DHT or flooding are possible solutions but
control/data plane separation allows more simple localization scheme. I think
it is worth considering control/data plane separation in a first approach,
while I agree that the fully distribution is more optimal.
Thanks.
--
IMARA Team, INRIA, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
#email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com
#webpage: http://sites.google.com/site/hurryon/